On Tue, 16.09.08 14:34, Janina Sajka (janina@xxxxxxxxxxx) 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
