Re: a11y: pulseaudio muted in squeeze by default
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.
Reply to: