Hi, On Do, Sep 30, 2010 at 01:57:49 +0200, Hynek Hanke wrote: > On 30.9.2010 11:49, Samuel Thibault wrote: > > I think you mentioned that the libao output doesn't have such blocking > > issue, Hynek, can you confirm this? > > No, using ALSA directly and using ALSA through libao > is still using ALSA, so in the described scenario, it will > still prevent Pulse Audio to start. Even if the user prefers > Pulse in all his configurations, Pulse audio will fail > to start because ALSA will mix in. So fallback is not > possible now.
right, because pulse wants exclusive access to the hardware. It opens hw0,0 so it would block alsa if started as first audio application. > Furthermore, libao doesn't contain a function to stop > the sound being played, which make it really unsuitable > for Speech Dispatcher :( We were however talking This is the second time you have written this. I think you haven't never tested it, because it took a very long time that the code was noticed and added to speechd by brailcom. BTW.: the improoved pulseaudio driver in speechd does alomost the same for stopping speech and is based on the libao driver (please compare). Both pulse and libao work now and is more usable then other audio backends in speechd. > about trying to extend libao with this functionality and > possibly use it instead of our own audio backends. That would be great but speechd could switch it in current state as well. > > This will probably a good enough > > reason for enabling libao support as fallback (which debian-release will > > have to agree on). > > > > I think the only solution here is either to > > 1) Do something in ALSA so that clients attached to DMIX > do not actually block Pulse from claiming the soundcard, > then reconnect those DMIX clients through Pulse. oh no! That will produce more problems then we can solve with this approach. > 2) Have Speech Dispatcher detach from the audio resource > when it's session becomes inactive. (So that it doesn't prevent > Pulse Audio in an active session to work the soundcard.) That was the reason why I wrote something about an audio-agent which does the audio handling for speech-dispatcher. This way speechd core server can run as system service and the audio handling only would depend on the active session :-). > Solution #2 sounds much simpler to me and solves the problem > for all audio backends, not just ALSA vs. Pulse, but requires > changes in Speech Dispatcher, so it won't help us for 0.7.1. 3. You have one more Chance to get this work if the pulseaudio developers wants to help :-). Pulseaudio is the only showstopper in these problems. It should implement a fallback mechanism if it can't get exclusive access to the audiohardware. That is my current setup. I have reconfigured pulse to use alsa's dmix plugin. So it can't block alsa and all soundsystems work nicely together (but that isn't recommended) by the pa devs. -- To UNSUBSCRIBE, email to debian-accessibility-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100930133450.ga12...@gentoo.local
