[alsa-devel] ALSA/pulseaudio problem workaround
superquad.vortex2 at gmail.com
Tue Mar 15 06:19:50 CET 2011
2011/3/15 Colin Guthrie <gmane at colin.guthr.ie>
> '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 at 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
This is because pulseaudio overwrite
> > 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.
you have to ask Unbuntu or Fedora to add this switch since it is not easy
for ordinary use to disable the use of pulseaudio after using
libcanberra-gtk-play to play the system event sound
> 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.
I have doubt about this since PA server cannot use RME9652 because the card
does not support 2 channel, so how can PA server release the device through
"device reservation protcol" when PA server cannot even reserve the sound
More information about the Alsa-devel