[alsa-devel] ALSA/pulseaudio problem workaround

Wed Mar 16 18:57:26 CET 2011

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 at 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 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.
>
> > 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/]
-------------- next part --------------
Audio Output Tests

1 Graphic login – unprivileged user

Notes:
GUI invocation via the Applications menu was used in all cases
An effort is was to find, and release spurious locks on audio resources before each program was invoked. KDE is is commonly at fault in these cases (e.g., with knotify4 opening a file in /dev/snd and not releasing it when it has done its (by the way, in my case unwanted) audio notification (usually of some event that is of no interest to me or that is already obvious). Most of these offenders were found with   lsof +c 0 -n | grep "/dev/snd" and then the process holding the device file open was killed. Note that there are cases in which there is a legitimate reason for these files to be open (as for example when hdspmixer is being actively used but that is not the case in any of these tests unless otherwise noted.
Three audio file formats were tested in each case (flac, wav, mp3).  Results marked as successful succeeded for all three formats unless otherwise noted. Results marked as unsuccessful failed for all three formats unless otherwise noted.
Program
Command
Result
Notes
Audacity
audacity
successful

Amarok
amarok %U
unsuccessful
PulseAudio Sound Server
Audacious
audacious2 %U
unsuccessful
Meter display OK
Banshee
banshee-1 --redirect-log --play-enqueued %U
unsuccessful
Played audio streamed from internet. Visual indications that Banshee thinks it is playing.
GNOME MPlayer
gnome-mplayer %U
unsuccessful
This applies equally to testing and accepting all defaults, choosing alsa as “Audio Output” and choosing “pulse” as “Audio Output”

Visual indicators show it playing each file
Gnome Music Player Client
gmpc
unsuccessful
mpd running ok & reports ”output: Successfully detected a alsa audio device”

Visually reports that it is playing each file

-------------- next part --------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: AudioTest01.odt
Type: application/vnd.oasis.opendocument.text
Size: 14625 bytes
Desc: not available
Url : http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20110316/8bef8872/attachment-0001.odt 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AudioTest01.pdf
Type: application/pdf
Size: 48509 bytes
Desc: not available
Url : http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20110316/8bef8872/attachment-0001.pdf 