[alsa-devel] ALSA/pulseaudio problem workaround

[Raymond Yau]

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
> working.
>

This is because pulseaudio overwrite

ctl.!default {
    type pulse
}


>
> > 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
card