Tried Pulse Audio Again--No Good For A11y

Lennart Poettering mzerqung at 0pointer.de
Mon Sep 22 23:57:31 UTC 2008


On Tue, 16.09.08 14:34, Janina Sajka (janina at rednote.net) wrote:

> 3.)	Logging in I hear first the GDM "audio logo," think I'll call it
> an earcon from now on. But, Orca launches in my secondary audio device.
> That's inappropriate, but I have no way to control that except to unplug
> my secondary and tertiary audio devices and start over.

In udev times ALSA devices don't have any particular order
anymore. Which one you consider "primary", "secondary" or "tertiary"
is known to you, but Linux doesn't know about that. Nowadays the
indexes of ALSA sound cards depend on the initialization order of the
drivers. Those drivers are now usually initialized in parallel which
hence results in different orders at each boot.

PA completely ignores alsa device indexes. Instead it uses HAL UDIs
for identifiying devices, which is much more useful. When PA is first
started up and no default audio device is configured, then PA will
pick one. It is not defined which one it will pick, and as it appears
it picked the wrong one for you.

After login you can change the default device by right-clicking on it
in paucontrol. However, that setting is per-user, so it won't have any
effect on gdm.

I thought of writing a small module for PA which in the case that no
default device is configured will try some heuristic to find a
suitable default (i.e. prefer PCI over USB over Bluetooth cards). Not
sure this would fully fix your problem though.

> 4.)	Logging back in with only one audio device on board, Orca does
> indeed startup on that device--but it seems I have to choose between
> Orca and playing other audio. How quaint! I thought we got past this
> silly "one sound at a time" view back around alsa-0.9. Does anyone
> recall the alsa FAQ used to claim this was appropriate back then?

I don't know how orca is configured. If it is a well behaving ALSA
client it should connect to the device called "default" which will
then result in a connection to PA. However, if it is a badly behaving
ALSA client and hardcodes device strings such as "hw:0" then orca
needs fixing.

> Well, it still isn't appropriate, but that's what's happening. If I
> paplay some .wav from a Gnome-Terminal, then attempt to go somewhere off
> my Alt-F1 (Applications) menu--there's no Orca until my .wav ends. I
> guess it would be like the screen blanking while the cd audio disc
> plays? Very curious, indeed.

This is intended behaviour. We will pause audio for inactive
sessions, to make sure that other users cannot eavesdrop on you when
they take over the active session. 

> 5.)	While I paplay, I try to go Ctrl-Alt-F1. While I'm not prevented
> from doing so, paplay believes it should pause playing while I'm away
> from the gui tty. Now, who's the genius that figured out this
> "feature?"

I did. And it actually is a feature. It fixes a long standing security
issue.

As long as you switch from/to sessions that are owned by the same user
audio stays on. We only suspend audio if you switch to a session owned
by a different user.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4




More information about the devel mailing list