[Pkg-pulseaudio-devel] Bug#519705: found causes of some of the issues

[Niels Boehm]

Okay, I've been looking a bit deeper into it, and that's what I was able to 
find:

> This heavily looks like /usr/lib/pulse-0.9/modules/module-alsa-sink.so ...

This is wrong, module-hal-detect.so was the culprit in my case, autoloading 
the detected alsa sound card with hw:* access. So one possible workaround 
would be disabling the module-hal-detect either by removing the containing 
package or by commenting it out in the default.pa or system.pa (whichever 
gets used in your case).

But that might leave the module-detect.so which I haven't tested for 
exhibiting this behaviour, so you might need to comment that out, too.

> to obtain exclusive access to an alsa device via "hw:" instead 
of "plughw:" ...

That's only half true. hw:* and plughw:* will both arbitrate exclusive 
access to the device, while plughw:* is able to resample the (single) 
stream, while hw:* is not.

So the solution is using dmix:*. In fact, dmix can by default (with 
unchanced alsa configuration) be accessed with the default:* syntax in 
addition to its actual name.

Thus there is a solution that doesn't require you to disable the hal module 
(So you can still plugin and use USB sound cards and the like).

Just insert the following line into your default.pa (if you use auto spawn 
mode) or system.pa (if you have it executed at system startup from 
initscripts), respectively. Make sure it comes before the hal module.

load-module module-alsa-sink device=dmix:0 format=s32 rate=48000

You could also say default instead of dmix (or leave out the device= 
argument completely), but then you have to make sure that the default is 
not changed in the alsa configuration. Especially not to redirecting to the 
alsa pulse plugin, since that would create a loop. The format= and rate= 
arguments are only for avoiding warning messages, since dmix has fixed 
parameters of 32bit and 48kHz in alsa's default config which deviates from 
pulse's default.

Then you only have to make sure that other applications that don't go 
through pulse play through alsa's dmix (or default, if the the default is 
dmix), then you'll be perfectly able to use those and pulse concurrently.


A totally different problem may be the default restrictive security settings 
when starting the pulseaudio server from initscripts, since in that case it 
won't automatically use and propagate authentication cookies through the X 
root window.

There is a really simple solution for that: Add your user that should be 
able to access pulse to the pulse-access group.


If you instead have pulse autospawn on use, try adding your user to the 
pulse-rt group, so pulseaudio can fiddle around with its priority. Maybe 
pulse doesn't like being unable to do that. (But I'm not using the 
autospawn approach, so I can only guess here.)


Regards,
Niels Böhm