Attached are the first results of my audio output tests on my system. Though this level of testing does not incorporate any of the suggestions that Colin had, this level of testing will perhaps establish a baseline for later tests that do act on those recommendations.
I am collection the test results in an odt format table (using OpenOffice.org Writer) for convenience and readability (files attached); However, mindful of Colins request for plain text communications, I have also exported to .txt html and pdf and attached those files.
Contrary to the expectations expressed by both Colin and Fernando, the rate of success in getting audio output from Fedora 14 applications without any tinkering in these first few tests (somewhat less than 20%) is, if anything, higher than I would expect based on my experience.
-- Craig
att: 4
On Mon, Mar 14, 2011 at 7:18 PM, Colin Guthrie gmane@colin.guthr.ie wrote:
'Twas brillig, and Craig Bourne at 14/03/11 21:31 did gyre and gimble:
The conditions that occasioned my feeling that Pulse "hijacks" ALSA resources is, e.g., reflected in the error message displayed in this exchange:
[root@speedy ~]# amixer ALSA lib pulse.c:229:(pulse_connect) PulseAudio: Unable to connect: Connection refused
amixer: Mixer attach default error: Connection refused
This is simply because alsa's default audio device is routed via PA. You can use e.g. amixer -c0 to get direct access ot the hardware, or you can do PULSE_LOG=99 amixer to get a more detailed log output of why it's not working.
Please try to see this from my point of view. I am only trying to use an ALSA utility to see what is wrong with my sound system (a diagnostic procedure that has been recommended by ALSA for some time). I have no business with pulseaudio. Yet the default case chooses a null card, based on what pulseaudio will recognize, rather than my perfectly good RME 9652 audio card which ALSA has recognized without help or interference from pulseaudio.
PulseAudio is built entirely on top of ALSA (on Linux at least). It is one of the only ALSA clients to make use of recent features in ALSA such as timer-based scheduling. We do not attempt to replace it or fight it in any way. That said there may be times when we offer an overly simplistic interface for certain users needs. If this is the case then that user is perfectly free to not use PulseAudio. Most sensible distros provide a simply tick box to disable the use of PulseAudio. If this is not provided by your distro then please complain to them.
I do not personally have such a card, so I cannot comment specifically on that particular card. I'd be surprised if PA does not detect it at all however. The dummy card is likely the result of not being able to open the device during login due to some other app "hogging" the sound device. This is purely guesswork on my part however.
A bit more tinkering and research jogs my memory and I recall that I can give these ALSA utilities a card number argument, and when I do I see the result that I expected to see as a default (not such a wild assumption since I have exactly one audio card installed, and ALSA recognizes that card, and this is after all an ALSA utility that I am trying to use). Had amixer, by the way, failed only with the last line of the message, I would not have the impression that pulseaudio was hijacking resources.
It's simply how your system is configured. If you don't want the "default" card in alsa to be PulseAudio, don't configure it that way. It's not "PulseAudio" that is magically hijacking the resources here, but the way your distro has configured things. If it doesn't suit you, you should use the tools provided by your distro to change that.
I should perhaps point out that one of the adjustments that I have made in the past to get ALSA and friends working was to remove all traces of pulseaudio. Working largely on representations such as you quote in your response, "/For the last couple years there has been an agreed protocol for graceful handover of the audio device between PA and JACK./" , I am accepting the developers' representations and trying to leave all their good work in place. Information that was "public and not hard to find", and that I could "google", suggested the radical excision of pulseaudio to get things working smoothly in the past. Since I took this approach I am not as well aware of how ALSA and pulseaudio have evolved together as perhaps you think I ought to be. Mea culpa.
I hope I wasn't too harsh in my first email. I didn't mean it that way - I guess you just get seasoned to be defensive at times.
Anyway, the "device reservation protocol" is programmed into jack AFAIK. When running jack-dbus it should request that PA leaves the devices alone and PA will comply. There is even a module for PA called jack-dbus-detect which will detect jack running and automatically load module-jack-sink to ensure that any PA apps will continue to output but via JACK then to ALSA rather than directly to PA's own ALSA sink. This isn't in a public release yet (and there are still issues with how this works in practice) but the idea is to get a graceful handover. If you don't care about PA (or ALSA without specific configuration) apps working when JACK is running then this isn't even an issue anyway.
If you need to remove PA, like I say above, your distro should provide that facility. If it does not the manual setup you have to do is to: 1. Ensure that PA is not run as a system-wide service (it shouldn't be anyway). 2. Ensure that the alsa configuration does not root the default device to PA (typically via /etc/alsa/<something>.conf but you can always trace this via /usr/share/alsa/alsa.conf) 3. Ensure that /usr/bin/start-pulseaudio-* do not run (just edit them and put an exit at the top). 4. Ensure autospawning is disabled (/etc/pulse/client.conf).
Doing all of the above (which I will stress again be wrapped up by the tools provided by your distro) should prevent PA from running and you can happily use just ALSA.
HTHs
Col
--
Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/
Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]