Comment 13 for bug 295832

Daniel T Chen <email address hidden> wrote:

> I don't agree with your assertion of a "configuration that cannot be
> overridden either by user or by local system settings". If you don't
> want the pulse pcm+ctl, then don't allow the pulseaudio daemon
> to run, e.g., kill it. /.../

That's sort of a "devil's choice" since pulseaudio is (or is becoming)
an integrated part of Gnome that other parts assume is running, thus
killing it makes various other things misbehave. In my particular case
I found it necessary to handle e.g. the system beep.

> Please note as well that, in a default Ubuntu configuration, the
> daemon will be invoked during session startup and will grab hw:*.

That's true in a default configuration, but it can be changed by local
settings. I have an /etc/asound.conf that adds dmix/plug devices on
top of the hw device, and I have corresponding local settings in
/etc/pulse/default.pa that makes it use those devices. This way I can
use pulseaudio for clients requiring it, together with clients that
use alsa directly (without passing through pulseaudio). Both work at
the same time, and I don't have hardware with multiopen support - alsa
does the mixing instead of pulseaudio.

This together with the change I'm currently forced to do in
/usr/share/alsa/pulse-alsa.conf is a quite well functioning setup.

My specific reason for not routing everything through pulseaudio is
that it still doesn't work well enough - I get choppy sound and
sometimes big latencies in some apps. This is hopefully a passing
problem, but nevertheless a big one for me right now. And my current
reason aside, there can always be many other reasons for not wanting
to route alsa traffic through pulseaudio and back again.

> I'm unsure how you intend to make pulseaudio work out of the box
> and to still effect ~/.asoundrc with highest priority. In the case
> where ~/.asoundrc conflicts with pulseaudio's pcm+ctl
> configuration, how do you wish ~/.asoundrc to remain effected,
> e.g., how would you add such logic checks?

I don't have any solution for that, I'm only pointing out the problem.
I guess it'd require some sort of priority system that controls hooks
too, which sounds like a fairly complex addition to alsa.

Because it appears to be nontrivial to solve "the right way", I
suggested instead only a sort of opt-out setting in
/etc/defaults/pulseaudio, so that it can be avoided at least on the
system level. Another alternative could perhaps be to place
/usr/share/alsa/pulse-alsa.conf (or a fragment of it) inside the /etc
tree.

And as for working out of the box, I can point out that the setup I've
outlined above works well straight away for most applications, in the
very common special case that they run locally and only need to access
the local sound hardware.