Daniel T Chen <crimsu...@yahoo.com> 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. -- Alsa does not honor pcm.!default in ~/.asoundrc because of /usr/share/alsa/pulse-alsa.conf https://bugs.launchpad.net/bugs/295832 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
