[alsa-devel] ALSA/pulseaudio problem workaround
Here is a workaround for the problem I described in my email to you yesterday:
Background My past experience with ALSA, JACK and many of the Linux audio tools that depend on them is that often some few applications in the tool-chain of a complex task will not work properly (or at all) unless invoked with *root* privileges. One is now frustrated in getting such things to work Fedora 14 as they have for the past decade or so in that the most basic tools (e.g., alsactl, QjackCtl) no longer work for root. Indeed, audio also does not work for unprivileged users on Fedora 14 either (though this evidently fails at a different level and will be taken up in a subsequent communication).
Symptoms alsactl fails carping about pulseaudio, audacity can be started on its own but no longer wants to cooperate with JACK and ALSA resulting in horribly distorted sound from something horked together in the background as a "favor" to the user, QjackCtl runs, produces messages, and blinks its cute little meter display but evidently does this off on the sidelines reporting 0 XRUNS even as every little jot and tiddle of computation produces a surprising audio result.
Strategy Based on my observation that PULSEAUDIO is evidently being allowed to interpose itself between the user (even the superuser) and ALSA, and since this user has been kept largely ignorant of the workings of all this and does not know the secret handshake, I will attempt to at least minimize the damage to audio and regain some measure of control while not attempting to disable the PULSEAUDIO/ALSA cabal.
Workaround
Install the following if they are not already on your system:
- avahi - padevchooser - pulseaudio-libs-zeroconf - pulseaudio-module-zeroconf
Enable and start the Avahi Daemon
Create these two shell scripts (that will be used by QjackCtl), make them executable, and place them in a directory where they will stay to be invoked each time QjackCtl is started:
PAjack_startup
#!/bin/bash # Name: PAjack_startup
pulseaudio -D --system #perhaps more fastidious than the above line is #pulseaudio -D --system --disallow-exit --disallow-module-loading padevchooser&
PAjack_shutdown
#!/bin/bash #Name: PAjack_shutdown
pulseaudio --kill killall padevchooser
Invoke QjackCtl click Setup select the Options tab tick the box "Execute script after Startup" and enter ~/bin/PAjack_startup [Note: using, of course the path to your script] tick the box "Execute script on Shutdown" and enter ~/bin/PAjack_shutdown [Note: as before, using your path to the file]
Quit QjackCtl -- your scripts will now be invoked the next time it is used.
A partial workaround for the unprivileged user, at least to the point of getting QjackCtl and audacious working places a slightly modified PAjack_startup script in a place where QjackCtl can find it when it starts with the changes used above for root (e.g., insure that both acounts have a subdirectory named "bin" in their home directory and have QjackCtl look for ~/bin/PAjack_startup when it is invoked).
Here is the script for unprivileged users:
#!/bin/bash #Name: PAjack_startup
pulseaudio -D padevchooser&
Limitations
This is not a general solution to the ALSA/PULSEAUDIO problems I am experiencing but it is a workaround that at least allows me to have some minimal functionality back from basic audio tools that I have come to rely on in my work as a composer.
'Twas brillig, and Craig Bourne at 13/03/11 21:05 did gyre and gimble:
Here is a workaround for the problem I described in my email to you yesterday:
Background My past experience with ALSA, JACK and many of the Linux audio tools that depend on them is that often some few applications in the tool-chain of a complex task will not work properly (or at all) unless invoked with *root* privileges. One is now frustrated in getting such things to work Fedora 14 as they have for the past decade or so in that the most basic tools (e.g., alsactl, QjackCtl) no longer work for root. Indeed, audio also does not work for unprivileged users on Fedora 14 either (though this evidently fails at a different level and will be taken up in a subsequent communication).
On a typical desktop, audio will work fine as root, provided the root privileges have been obtained via a graphical login as a normal user and the "su" command. By virtue of being able to access the X11 root window, the root user will be able to communicate with the PA daemon of the running user just fine. It relies on the start-pulseaudio-x11 script having been run which is the case on a typical login.
As a general rule however, you should not need to do anything as root. Using root for purposes other than sysadmin is generally discouraged and unnecessary.
Symptoms alsactl fails carping about pulseaudio, audacity can be started on its own but no longer wants to cooperate with JACK and ALSA resulting in horribly distorted sound from something horked together in the background as a "favor" to the user, QjackCtl runs, produces messages, and blinks its cute little meter display but evidently does this off on the sidelines reporting 0 XRUNS even as every little jot and tiddle of computation produces a surprising audio result.
Strategy Based on my observation that PULSEAUDIO is evidently being allowed to interpose itself between the user (even the superuser) and ALSA, and since this user has been kept largely ignorant of the workings of all this and does not know the secret handshake, I will attempt to at least minimize the damage to audio and regain some measure of control while not attempting to disable the PULSEAUDIO/ALSA cabal.
It's really not that complicated. You're making this out to be a big deal, but really all you need to do is google a little and/or ask the PA community via the mailing list or IRC. You make it sound like we're trying to kidnap you in the middle of the night or something. Please don't resort to unnecessary hyperbole.
Workaround
Install the following if they are not already on your system:
- avahi
- padevchooser
- pulseaudio-libs-zeroconf
- pulseaudio-module-zeroconf
Enable and start the Avahi Daemon
Create these two shell scripts (that will be used by QjackCtl), make them executable, and place them in a directory where they will stay to be invoked each time QjackCtl is started:
PAjack_startup
#!/bin/bash # Name: PAjack_startup
pulseaudio -D --system #perhaps more fastidious than the above line is #pulseaudio -D --system --disallow-exit --disallow-module-loading padevchooser&
System wide mode is very much discouraged in a typical setup. Per-user operation is the typical setup installed OOTB on most/all linux distros.
Also please note that padevchooser has been obsolete for some years and we do not recommend it's use.
PAjack_shutdown
...snip...
This typically won't work. Most PA setups are per-user and with auto-spawn enabled. You would have to address this situation to cover the bases.
This is not a general solution to the ALSA/PULSEAUDIO problems I am experiencing but it is a workaround that at least allows me to have some minimal functionality back from basic audio tools that I have come to rely on in my work as a composer.
For the last couple years there has been an agreed protocol for graceful handover of the audio device between PA and JACK. This is a DBUS protocol and if JACK asks for the audio device, PA happily relinquishes control of the device.
This support has been built into jack for a while when build with dbus support.
Again, all of this information is public and not hard to find.
I'd advice you simply ask first, before spending hours banging your head of a brick wall trying to find hacky solutions.
I'd be happy to discuss this with you and offer you advice, but I'm not a JACK expert and do not use it personally. There are other people from the PA community who are more involved with JACK stuff however, so I would suggest using the pulseaudio-discuss list to make contact and get advice.
Col
"Have you guessed the riddle yet?" the Hatter said, turning to Alice again. "No, I give it up," Alice replied. "What's the answer?"
Thank you very much for the feedback. I appreciate it and would appreciate further suggestions on a more functional approach to dealing with these issues.
With respect to this advice:
On a typical desktop, audio will work fine as root, provided the root privileges have been obtained via a graphical login as a normal user and the "su" command. By virtue of being able to access the X11 root window, the root user will be able to communicate with the PA daemon of the running user just fine. It relies on the start-pulseaudio-x11 script having been run which is the case on a typical login.
As a general rule however, you should not need to do anything as root. Using root for purposes other than sysadmin is generally discouraged and unnecessary.
This experience is at variance with your assertions:
*Graphical login as cbourne [an unprivileged user] from a terminal session su as root*
[root@speedy cbourne]# audacity
(Audacity:20310): GnomeUI-WARNING **: While connecting to session manager: None of the authentication protocols specified are supported. ** GLib-GIO:ERROR:gdbusconnection.c:2270:initable_init: assertion failed: (connection->initialization_error == NULL) Aborted (core dumped) [root@speedy cbourne]#
*Graphical login** as cbourne from a normal terminal session *
[cbourne@speedy ~]$ audacity Cannot connect to server socket err = No such file or directory Cannot connect to server socket jack server is not running or cannot be started Expression 'stream->capture.pcm' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 3653 VST_PATH not set, defaulting to /home/cbourne/vst:/usr/local/lib/vst:/usr/lib/vst
(Audacity:20315): GLib-GObject-WARNING **: gsignal.c:2392: instance `0xac3e758' has no handler with id `6850'
(Audacity:20315): GLib-GObject-WARNING **: gsignal.c:2392: instance `0xa64a490' has no handler with id `124'
(Audacity:20315): GLib-GObject-WARNING **: gsignal.c:2392: instance `0xa932080' has no handler with id `197'
... (more warnings)
[ It should be noted that, despite the error response, audacity produce audible output only if jack is NOT running-- else, if jack is running, everything looks normal but there is no sound ]
*Graphical login** in as root ** from a terminal session under that login * [root@speedy ~]# audacity Cannot connect to server socket err = No such file or directory Cannot connect to server socket jack server is not running or cannot be started Expression 'stream->capture.pcm' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 3653 VST_PATH not set, defaulting to /root/vst:/usr/local/lib/vst:/usr/lib/vst
(Audacity:20805): GLib-GObject-WARNING **: gsignal.c:2392: instance `0xabe5758' has no handler with id `6880'
(Audacity:20805): GLib-GObject-WARNING **: gsignal.c:2392: instance `0xa666490' has no handler with id `124'
(Audacity:20805): GLib-GObject-WARNING **: gsignal.c:2392: instance `0xa9cc080' has no handler with id `197'
... (more warnings)
[ Here sound is produced by audacity 1) without jack running, 2) with jack running using the startup/shutdown scripts 3) with jack running but without the scripts. Though I have no metrics to share with you to support this, it is my repeated observation that procedures 1) and 3) produce far more noise than does procedure 2) in this testing scenario. ]
I would of course prefer to adhere to current best practice as I attempt to address these issues rather than flailing about with deprecated and inappropriate methods. The means of doing this is less clear to me than you may suppose, and not for want of exploring the material posted on-line where, e.g.,, the ALSA web site offers what I presume to be current information along with articles that are, in whole or in part, clearly out of date. But what is out of date is not always clearly so.
As of Fedora 12 I was able (with some considerable struggle) to get all of the jack/ALSA and all the applications that use them functioning properly. With the change to Fedora 14 the struggle started again-- but I was able to get most of the applications that I had come to rely on working again. With the latest set of changes in fedora 14 (including many changes in ALSA) nothing works.
And so 'Tis indeed brillig, and Craig Bourne at 14/03/11 13:57 continues gyre and gimble
[Friendly request: If possible, please try to keep replies to plain text only, and use standard mailing list quoting styles. This makes it much easier for people who read many hundreds of such emails every day to get a consistent style and thus human-parse emails more easily and reply-to-the-reply in a standard way too :) Thanks.]
'Twas brillig, and Craig Bourne at 14/03/11 18:00 did gyre and gimble:
"Have you guessed the riddle yet?" the Hatter said, turning to Alice again. "No, I give it up," Alice replied. "What's the answer?"
:D
Thank you very much for the feedback. I appreciate it and would appreciate further suggestions on a more functional approach to dealing with these issues.
With respect to this advice:
On a typical desktop, audio will work fine as root, provided the root privileges have been obtained via a graphical login as a normal user and the "su" command. By virtue of being able to access the X11 root window, the root user will be able to communicate with the PA daemon of the running user just fine. It relies on the start-pulseaudio-x11 script having been run which is the case on a typical login.
As a general rule however, you should not need to do anything as root. Using root for purposes other than sysadmin is generally discouraged and unnecessary.
This experience is at variance with your assertions:
*Graphical login as cbourne [an unprivileged user] from a terminal session su as root*
[root@speedy cbourne]# audacity
(Audacity:20310): GnomeUI-WARNING **: While connecting to session manager: None of the authentication protocols specified are supported. ** GLib-GIO:ERROR:gdbusconnection.c:2270:initable_init: assertion failed: (connection->initialization_error == NULL) Aborted (core dumped) [root@speedy cbourne]#
Running audacity as root is very different to "accessing pulseaudio as root". There are lots of other things that may get in the way, for numerous reasons, of running a full blown GUI app that is beyond the scope of libalsa and libpulse.
On my system here for example: [colin@jimmy ~]$ xprop -root | grep PULSE_SERVER PULSE_SERVER(STRING) = "{6cb2a4b2bd6df042e57da8a4000001d4}unix:/home/colin/.pulse/6cb2a4b2bd6df042e57da8a4000001d4-runtime/native tcp:jimmy:4713 tcp6:jimmy:4713" [colin@jimmy ~]$ sudo -i [root@jimmy ~]# xprop -root | grep PULSE_SERVER PULSE_SERVER(STRING) = "{6cb2a4b2bd6df042e57da8a4000001d4}unix:/home/colin/.pulse/6cb2a4b2bd6df042e57da8a4000001d4-runtime/native tcp:jimmy:4713 tcp6:jimmy:4713" [root@jimmy ~]# paplay /usr/share/sounds/pop.wav
Provided the root user can access the X11 window of the user in question (the user with the active session - see ck-list-sessions) and provided the root user can access the physical socket file, then it will be able to talk to and communicate with the user's PA daemon.
What I've not included here is the PULSE_COOKIE X11 prop, which is also used so that root can authenticate to the user's PA. Access to the X11 root window is considered enough for us to allow the user to access the sound too.
*Graphical login**as cbourne from a normal terminal session *
[cbourne@speedy ~]$ audacity Cannot connect to server socket err = No such file or directory Cannot connect to server socket jack server is not running or cannot be started Expression 'stream->capture.pcm' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 3653 VST_PATH not set, defaulting to /home/cbourne/vst:/usr/local/lib/vst:/usr/lib/vst
(Audacity:20315): GLib-GObject-WARNING **: gsignal.c:2392: instance `0xac3e758' has no handler with id `6850'
(Audacity:20315): GLib-GObject-WARNING **: gsignal.c:2392: instance `0xa64a490' has no handler with id `124'
(Audacity:20315): GLib-GObject-WARNING **: gsignal.c:2392: instance `0xa932080' has no handler with id `197'
... (more warnings)
[ It should be noted that, despite the error response, audacity produce audible output only if jack is NOT running-- else, if jack is running, everything looks normal but there is no sound ]
I can run audacity fine:
[colin@jimmy ~]$ audacity Cannot connect to server socket err = No such file or directory Cannot connect to server socket jack server is not running or cannot be started Expression 'stream->capture.pcm' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 3653
Everything works fine with PA underneath.
As far as the sound setup is considered, the Host is "ALSA" with playback and recording devices set to "default".
*Graphical login**in as root **from a terminal session under that login
[root@speedy ~]# audacity Cannot connect to server socket err = No such file or directory Cannot connect to server socket jack server is not running or cannot be started Expression 'stream->capture.pcm' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 3653 VST_PATH not set, defaulting to /root/vst:/usr/local/lib/vst:/usr/lib/vst
(Audacity:20805): GLib-GObject-WARNING **: gsignal.c:2392: instance `0xabe5758' has no handler with id `6880'
(Audacity:20805): GLib-GObject-WARNING **: gsignal.c:2392: instance `0xa666490' has no handler with id `124'
(Audacity:20805): GLib-GObject-WARNING **: gsignal.c:2392: instance `0xa9cc080' has no handler with id `197'
... (more warnings)
[ Here sound is produced by audacity 1) without jack running, 2) with jack running using the startup/shutdown scripts 3) with jack running but without the scripts. Though I have no metrics to share with you to support this, it is my repeated observation that procedures 1) and 3) produce far more noise than does procedure 2) in this testing scenario. ]
I can't really comment on the JACK setup as I don't have it running.
I would of course prefer to adhere to current best practice as I attempt to address these issues rather than flailing about with deprecated and inappropriate methods. The means of doing this is less clear to me than you may suppose, and not for want of exploring the material posted on-line where, e.g.,, the ALSA web site offers what I presume to be current information along with articles that are, in whole or in part, clearly out of date. But what is out of date is not always clearly so.
I presume you have a direct need and desire for running JACK? I won't question that, just want to make sure you're genuinely wanting it or seeing it as a "means to an end" (which I don't think is the case, but you gotta ask :D)
As of Fedora 12 I was able (with some considerable struggle) to get all of the jack/ALSA and all the applications that use them functioning properly. With the change to Fedora 14 the struggle started again-- but I was able to get most of the applications that I had come to rely on working again. With the latest set of changes in fedora 14 (including many changes in ALSA) nothing works.
I suspect this is party a hangover from upgrades.
Running system-wide PA is generally not recommended - tho' it's not clear that this is the case.
Things to check:
1. ck-list-sessions: Make sure you user is correctly setup and that you are the "active=TRUE" session. 2. getfacl /dev/snd/*: Make sure that when your session is active, your user is included with rw access in the ACL. 3. Make sure your user is NOT in the audio group. 4. Make sure PA autospawn is active (check both /etc/pulse/client.conf and ~/.pulse/client.conf) 5. Ensure that start-pulseaudio-x11 is installed and run at login (checking via xprop as indicated above is a good test). 6. Check that becoming root still allows you to access the X11 root window of the user (xprop again) 7. Test paplay as root to confirm the above fully. 8. Run pavucontrol and confirm: 8a) aplay /path/to/file.wav: shows up under the "Playback" tab when running. 8b) arecord: shows up under "Recording" tab when running.
This confirms a typical setup with PA is all working and correct.
If you want to run jack, you can use the jack-dbus stuff for a graceful handover and suspension of PA or you can use "pasuspender -- myaudioapp" to ensure that pulseaudio will suspend it's access to the audio devices when running myaudioapp. You will have to ensure that myaudioapp does not use the "default" audio devices as these map to PA. You can theoretically configure audacity to run jack as needed and if you run it via pasuspender then you don't have to worry about PA accessing the audio devices.
I hope this info helps you find a more graceful solution and explains a bit how things fit together.
Col
2011/3/15 Craig Bourne craigbourne@gmail.com
[cbourne@speedy ~]$ audacity Cannot connect to server socket err = No such file or directory Cannot connect to server socket jack server is not running or cannot be started Expression 'stream->capture.pcm' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 3653
[ It should be noted that, despite the error response, audacity produce
audible output only if jack is NOT running-- else, if jack is running, everything looks normal but there is no sound ]
[ Here sound is produced by audacity 1) without jack running, 2) with jackrunning using the startup/shutdown scripts 3) with jack running but without
the scripts. Though I have no metrics to share with you to support this, it is my repeated observation that procedures 1) and 3) produce far more noise than does procedure 2) in this testing scenario. ]
it is because audacity use portaudio and there are three hostapi ( backend ) : alsa ,oss and jack on linux
"Host :ALSA " or "Host :JACK" in audacity preference - "Devices" - "Interface"
When portauio initialise , it will probe all the devices of available hostapi for the user to select in "Preference"
so it will try to connect to JACK server to find out whether it support duplex or not
For alsa builddevicelist() add those "hw" devices of the sound cards , it also add some"plugin" which is not in ignored list and finally two devices "dmix" and "default"
seem the message 'stream->capture.pcm' is related to "dmix" since "dsnoop" is in the ignored list
if you are still using "pcm.pulse" as "default" and does not disable autospwan of PA server ,PA server may autospawn to compete with JACK server for the sound card
I have dobut about using "Jack" and "Pulse" at the same time since "Jack" application usually aim at "low latency" while "Pulseaudio" is aim at reducing the number of wakeup for "power saving"
with respect to your analysis:
It's really not that complicated. You're making this out to be a big deal, but really all you need to do is google a little and/or ask the PA community via the mailing list or IRC. You make it sound like we're trying to kidnap you in the middle of the night or something. Please don't resort to unnecessary hyperbole.
Well, you did manage to parse my expression pretty well despite its being too hyperbolic.
I should have been clearer that from my seat it looked like ALSA resources were being hijacked by pulseaudio. It is that which I would have wished you to understand rather than, "we're trying to kidnap you in the middle of the night or something." The "middle of the night" thing, though unintended, is near enough to the facts-- I started flailing about for a solution ca. 3:30 am of the same day.
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
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.
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.
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.
'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
2011/3/15 Colin Guthrie gmane@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@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
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/]
'Twas brillig, and Craig Bourne at 16/03/11 17:57 did gyre and gimble:
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.
While you tests are interesting, I'm not really sure they are relevant to the ALSA mailing list.
This is primarily a distribution-related discussion in how things are configured and setup OOTB on a Fedora install.
It is perhaps more appropriate to that that discussion to a fedora-specific list.
If you keep me CC'ed in such discussions, I'd be happy to lent any insights I can.
In order to integrate PulseAudio properly in a distribution, many different components are configured to use PA by default. This includes e.g. Phonon on KDE, GStreamer and other audio output libraries (e.g. libao) and applications (e.g. mplayer). Many of these apps/framesworks should degrade gracefully in the event that PA is not running, but some may require specific setup to use alsa directly if the OOTB experience is designed to be a PA-based one. Depending on how much effort the distribution puts on to making PA optional will depend on your experience in this regard.
I would recommend testing your results against, e.g. Mandriva (or the Mageia alpha2) which offers a ticky box to disable PA and see how you get on. If the results are the same then I can help look at this as a more distro-agnostic issue, but if it works fine, then you obviously need to go poke Fedora.
But like I say, this discussion actually has very little to do with the upstream ALSA project.
Cheers
Col
2011/3/14 Craig Bourne craigbourne@gmail.com
Here is a workaround for the problem I described in my email to you yesterday:
Symptoms alsactl fails carping about pulseaudio,
seem alsactl is replaced by a stub program which does not perform anything
you have to file bug or ask in fedora forum
audacity can be started on its own but no longer wants to cooperate with JACK and ALSA resulting in horribly distorted sound from something horked together in the background as a "favor" to the user,
Cannot connect to server socket err= no such file or directory Cannot connect to server socket Jack server is not running or cannot be started Expression 'stream->capture.pcm' failed in 'src/hostapi/share/alsa/pa_linux.c' line:3503
seem bug in portaudio
QjackCtl runs, produces messages, and blinks its cute
little meter display but evidently does this off on the sidelines reporting 0 XRUNS even as every little jot and tiddle of computation produces a surprising audio result.
This look like bug since install Qjackctl-0.3.7-1-fc14 require to install portaudio-9-19-fc12 as qjackctl only require jack-audio-connection
participants (3)
-
Colin Guthrie -
Craig Bourne -
Raymond Yau