On Thu, 2009-08-06 at 23:27 +0300, Maxim Levitsky wrote: > On Thu, 2009-08-06 at 16:20 +0200, Lennart Poettering wrote: > > On Thu, 06.08.09 17:06, Maxim Levitsky (maximlevitsky at gmail.com) wrote: > > > > > So I carefully set everything up for it, and it now works (except 32 bit > > > compat libraries for skype ) > > > > > > Speaking of 32 bit compat libraries, is there a tutorial how to compile > > > these? (It isn't trivial, since I need alsa, pa libraries and plugins > > > for alsa) > > > > No clue. Multilib is a desaster. If you want this at all, use what > > your distro provides you with. > > > > > 1 - all sounds played through libcanberra (using pulse backend) (which > > > was installed from source (everything from latest git branches), play on > > > right speaker only, and this is confirmed by pavucontrol which display > > > the volume for notify sound briefly (which I consider a bug on its own, > > > because this makes it impossible to change a stream location - clicking > > > on the stream chooser button, takes focus out of it, thus prevents > > > device list from being shown) > > > It displays "front right" > > > > Hmm, is it possible that this is related to spacial events sounds? > > i.e. if you trigger them on the right side of the screen they are > > moved to your right speakers? If you trigger them on the left side of > > the screen they are triggered on the left side? If that's the case, > > then this is a feature, not a bug. > > > > Otherwise, I have never heard of this bug. If you remove > > ~/.pulse/*stream-volumes.tdb and restart PA. Does that fix the issue? > > > > > 2 - flat volumes are evil. It feels like a feature being removed. Now > > > changing a volume for a stream directly affects main volume, and alsa > > > volume through it. > > > I though that one of main PA features, was a volume control per stream. > > > Could you explain me what flat volumes are (I know that turning them off > > > fixes this issue)? > > > > The device volume is fixed to max of all the stream volumes. That's > > all. > > > > If you have one stream at -2dB, one at -1dB and one at -3dB then the > > device volume will be fixed to -1dB. if you then scale the device > > volume this will be reflected equally on the stream volumes. If you > > change a stream volume this will only then affect the device volume if > > it is the "loudest" one which you modify. > > > > It's actually pretty easy. > > > > > 3 - PA sometimes dies, and it is impossible to make it log to a file, > > > other that writing a wrapper script. Wrapper script doesn't help much > > > ether, as new autostart feature, tries to launch many copies of PA, and > > > only one starts. This creates a lots of 'false positives' > > > I can disable autostart, but then, I need to write a tool to autostart > > > and restart it, maybe this is the right solution. > > > (syslog doesn't seem to be able to put an output of a daemon to a file. > > > of course I can grep the log files, but having a clean seperate log > > > files seems to be better. > > > > Please set log-level=debug in daemon.conf and the debug output should > > end up in syslog. > > > > Which distribution is this? For tsched to work fine you need a *very* > > recent kernel (i.e. as in "not released yet") which provides a fixed > > snd_pcm_avail(). > It is disabled btw, by ubuntu patches I carefully applied from ubuntu > package of karamic. > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=506075 > > https://bugzilla.redhat.com/show_bug.cgi?id=501769 > > > > > And recently I did another update of alsa library, and PA. > > > Now controlling the sound via gstreamer (from gnome-volume-control, and > > > other places like applet, sound wheel) is broken, now > > > it works like that, first slider seems to work, but then it stops > > > updating the volume, untill I close and start mixer again, (or select a > > > different device from device list in gnome-volume-control, and back) > > > and it repeats > > > > Sounds as if PA simply dies due to the mentioned snd_pcm_avail() > > problems. > > I narrowed it down to: > > > > #define UPDATE_DELAY 50000 > > static void > restart_time_event (GstPulseMixerCtrl * c) > { > struct timeval tv; > pa_mainloop_api *api; > > g_assert (c); > > if (c->time_event) > return; > > /* Updating the volume too often will cause a lot of traffic > * when accessing a networked server. Therefore we make sure > * to update the volume only once every 50ms */ > > api = pa_threaded_mainloop_get_api (c->mainloop); > > c->time_event = > api->time_new (api, pa_timeval_add (pa_gettimeofday (&tv), > UPDATE_DELAY), > gst_pulsemixer_ctrl_timeout_event, c); > } > > > > > restart_time_event is called always, but > gst_pulsemixer_ctrl_timeout_event isn't called when volume gets stuck. On top of that, there seems to be two pulse threads. One of which (thread that is created when opening a PA device in mixer. gets stuck in poll. when I put a gdb tracing breakpoint there, bug disappeared.) Maybe PA gets stuck with too much requests. Bug happens without flat volumes as well 71 /* Before entering poll() we unlock the mutex, so that 72 * avahi_simple_poll_quit() can succeed from another thread. */ 73 74 pa_mutex_unlock(mutex); 75 r = poll(ufds, nfds, timeout); 76 pa_mutex_lock(mutex); 77 78 return r; > > > > Best regards, > Maxim Levitsky > > > > > > Also note that recent g-v-c does not user Gst anymore, but connects > > directly to pa. Make sure to use that as Gst's mixer abstraction is > > uh, less than awesome. > > > > Lennart > > >
