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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
