Alsa does not honor pcm.!default because of /usr/share/alsa/pulse.conf

Bug #295832 reported by Lucas Gadani on 2008-11-09
38
This bug affects 6 people
Affects Status Importance Assigned to Milestone
pulseaudio (Ubuntu)
Low
Daniel T Chen
Intrepid
Undecided
Unassigned

Bug Description

SRU information follows:

Impact statement: Users of Ubuntu 8.10 find that their /etc/asound.conf and ~/.asoundrc are ignored due to missing entries in /usr/share/alsa/pulse.conf. This symptom affects all users with the pulseaudio package installed *and* the daemon (regardless of system-wide or per-user session instance) running.

Bug resolution: The missing lines [referencing /etc/asound.conf and ~/.asoundrc] are added to /usr/share/alsa/pulse.conf. The change to the errors line mimics libasound2's /usr/share/alsa/alsa.conf [to not throw an error upon a missing ~/.asoundrc]. With these changes, users of default Ubuntu 8.10 will have their /etc/asound.conf and ~/.asoundrc, if extant, honoured with higher priority than the configuration shipped by pulseaudio, thereby restoring expected alsa-lib runtime conf behaviour (for native ALSA applications) prior to intrepid. If either /etc/asound.conf or ~/.asoundrc is missing, the current intrepid behaviour of pulseaudio overriding {pcm,ctl}.default is retained. This change is shown via Loggerhead here: http://bazaar.launchpad.net/~crimsun/pulseaudio/ubuntu/revision/38?remember=36&compare_revid=36.

SRU patch: http://launchpadlibrarian.net/21333323/pulseaudio_0.9.10-2ubuntu9.3.debdiff

Instructions to reproduce the symptom: Create an ~/.asoundrc with the following contents only:

# --- begin ---
pcm.!default {
   type plug
   slave hw:5,0
}

ctl.!default {
   type hw
   card 5
}
# --- end ---

After a fresh GNOME session login, open Applications> Accessories> Terminal, and use `speaker-test -Ddefault -c2' to verify that:
1) the speaker-test output continues to play (until interrupt, ctrl+c) through the PulseAudio-configured default device;
2) no errors are generated by alsa-lib.

These two symptoms verify that ~/.asoundrc is ignored.

Regression potential: Users who have a misconfigured /etc/asound.conf or ~/.asoundrc will notice that native ALSA apps refuse to start and throw alsa-lib error(s), which can be resolved by removing the offending conffile.

Original description follows:

Binary package hint: pulseaudio

Even if I define a pcm.!default section in ~/.asoundrc, /usr/share/pulse-alsa.conf overrides this definition, so the default alsa output is always pulseaudio.

If I comment the pcm.!default and ctl.!default in /usr/share/alsa/pulse-alsa.conf everything behaves as normal.

Using Intrepid amd64.

Martin Stjernholm (msub) wrote :

Bug #198453 contains a long discussion about this, and although I haven't read it thoroughly, the gist is apparently that it's generally a good thing to do that override.

Still, people might have any number of reasons for wanting things their own way. I guess a problem here is that the alsa config files doesn't provide a way for letting local configuration properly override hook based configuration.

In the meantime, until that is fixed, I suggest an option in /etc/default/pulseaudio to disable the overrides of pcm.!default and ctl.!default. That way it's at least possible to cope in a system level without resorting to editing files outside /etc.

Lucas Gadani (lgadani) wrote :

I understand that it might be a good idea to leave pulse as default on new Ubuntu installations, however it should be possible to override this setting with a file in /etc or user's home folder.

Currently, the only way to disable this option is editing a file in /usr/share .

Maybe pulseaudio could provide an option through debconf that sets it as the default alsa output, so we could disable without changing files inside /usr/share .

Daniel T Chen (crimsun) wrote :

I can't reproduce this symptom in 9.04. Please try again.

Changed in pulseaudio:
status: New → Incomplete
Lucas Gadani (lgadani) wrote :

I don't have 9.04 here, but I can still reproduce this symptom in 8.10.

Lucas Gadani (lgadani) wrote :

I've installed Ubuntu 9.04 alpha 2 and applied all the updates for this test. I don't have two sound cards in this test machine, so I can't confirm exactly the same behaviour, but I've made a simpler test as described below and I believe the problem is still present.

- start alsamixer
  - check that default mixer is pulseaudio

- create a ~/.asoundrc file with the following content:

--- cut here ---
ctl.!default {
  type hw
  card 0
}
--- cut here ---

- start alsamixer
  - check default mixer and it's still pulseaudio (bug!). ~/.asoundrc should override default settings, but it's not working.

- comment ctl.!default entry in /usr/share/alsa/pulse-alsa.conf

- start alsamixer
  - check that hw:0 mixer is the default mixer.

- change ~/.asoundrc with the following content:

--- cut here ---
ctl.!default {
  type pulse
}
--- cut here ---

- start alsamixer
  - check that pulseaudio is the default mixer. just to make sure ~/.asoundrc is being read. (ok!)

So, the conclusion is that's not possible to change default alsa devices without changing files in /usr/share.

Daniel T Chen (crimsun) wrote :

Please note that your ~/.asoundrc is incomplete. You are only overriding the control definition; you need also to override the pcm definition(s), e.g.,

pcm.!default {
   type plug
   slave hw:0,0
}

ctl.!default {
   type hw
   card 0
}

Lucas Gadani (lgadani) wrote :

Yes I understand, however, even when overriding the pcm.!default I have exactly the same problem with Jaunty 9.04 or Intrepid 8.10.

How are you trying to reproduce this? What are the steps you're doing while trying to reproduce this bug?

I was able to reproduce this using a kvm image with 2 sound cards. Pulse is always the default regardless of the setting in ~/.asoundrc , unless I change /usr/share/alsa/pulse-alsa.conf . I could provide you disk images reproducing this bug and/or a video of how to do it.

The exact same .asoundrc used to work with Hardy 8.04 and Gentoo Linux, so I'm pretty sure this is a problem with Ubuntu's current pulse package.

Daniel T Chen (crimsun) wrote :

I tested using the ~/.asoundrc pasted in my previous comment. I can also use a second (hw:1) usb audio device. PulseAudio, in its default configuration returns an error, as proper/expected.

Daniel T Chen (crimsun) wrote :

I've just verified the following:

1) a default jaunty daily-live skips ~/.asoundrc if pulseaudio is running
2) a default jaunty daily-live honours ~/.asoundrc if pulseaudio is *not* running

As this behaviour is intentional (note the name of the hook!), I'm closing this bug.

Changed in alsa-plugins:
status: Incomplete → Invalid
Martin Stjernholm (msub) wrote :

Intentional or not, it's bad behavior: It's clearly a dist configuration that cannot be overridden either by user or by local system settings. As said earlier: People might have any number of reasons for not wanting this hardcoded override that the pulse package does.

The default pcm/ctl is configurable in alsa, it no longer is when pulseaudio is running. If this pcm/ctl override were the only or prime reason to run pulseaudio then it'd be ok, but that's not the case.

I therefore persist: It would be good if this was overridable at least on the system level, typically through a setting in /etc/default/pulseaudio.

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. I concur that there is a usability bug in not being
able to easily {en,dis}able the daemon, but it's a bit of a stretch to
assert that the pcm+ctl configuration can't be overridden.

Please note as well that, in a default Ubuntu configuration, the
daemon will be invoked during session startup and will grab hw:*.
In such a case, ~/.asoundrc will be unusable involving hw:* unless
the hardware supports multiopen. Therefore, it is very much the
intent of the pulseaudio package to provide a pcm+ctl
configuration that overrides any other setting when the daemon is
active. You *must* disable the daemon (as noted above) to stop
this action.

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?

----- Original Message ----
From: Martin Stjernholm <email address hidden>
To: <email address hidden>
Sent: Friday, January 16, 2009 4:51:14 AM
Subject: [Bug 295832] Re: Alsa does not honor pcm.!default in ~/.asoundrc because of /usr/share/alsa/pulse-alsa.conf

Intentional or not, it's bad behavior: It's clearly a dist configuration
that cannot be overridden either by user or by local system settings. As
said earlier: People might have any number of reasons for not wanting
this hardcoded override that the pulse package does.

The default pcm/ctl is configurable in alsa, it no longer is when
pulseaudio is running. If this pcm/ctl override were the only or prime
reason to run pulseaudio then it'd be ok, but that's not the case.

I therefore persist: It would be good if this was overridable at least
on the system level, typically through a setting in
/etc/default/pulseaudio.

I also think it's bad behaviour. I have a sound card that supports multiopen, so I wanted to have both pulseaudio running and not have pulseaudio grabbing pcm.!default (because of some incompatibilities). Unfortunately, this is not possible without changing /usr/share/alsa/pulse-alsa.conf.

Maybe pulseaudio could have it's alsa configuration in /etc/asound.conf (so the root could override the configuration) or in /etc/skel/.asoundrc (so that every new user will have pulseaudio enabled by default, but overridable in it's configurations).

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.

Daniel T Chen (crimsun) on 2009-01-18
Changed in alsa-plugins:
assignee: nobody → crimsun
importance: Undecided → Low
status: Invalid → New
Daniel T Chen (crimsun) on 2009-01-18
description: updated
Changed in pulseaudio:
status: New → Fix Committed
Daniel T Chen (crimsun) on 2009-01-18
description: updated
Martin Stjernholm (msub) wrote :

A novel solution. I trust the repeated loading of ~/.asoundrc doesn't have any observable side-effects.

I note that this fix only allows for an override in ~/.asoundrc - making one in /etc/asound.conf still won't take effect. The obvious extension of the fix is to include /etc/asound.conf too in the repeated loading.

Daniel T Chen (crimsun) wrote :
description: updated
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package pulseaudio - 0.9.14-0ubuntu1

---------------
pulseaudio (0.9.14-0ubuntu1) jaunty; urgency=low

  * New upstream release. (LP: #317502, #317613)
  * Dropped patches, all in upstream release.
    - 0003-make-sure-to-use-64bit-rounding-even-on-32bit-machin.patch
    - 0004-properly-remove-dbus-matches-an-filters-when-unloadi.patch
    - 0005-Fix-two-typos-that-broke-tunnels.patch
    - 0008_regen_autotools.patch
    - 0009_shm-arch-indep.patch
    - 0010_check_before_using_environment.patch
    - 0011_load_restore_before_other_modules.patch
    - 0013_dont_hit_assert_issuing_two_rewinds_in_single_iter.patch
    - 0014_retry_without_snd-pcm-no-auto-format.patch
    - 0015_use_fionread.patch
    - 0016_add_pa-source-message-get-latency.patch
    - 0017_allow_dev_dsp_w-ok.patch
    - 0019_fix_macro_pa-unlikely.patch
    - 0020_catch_driver_errors.patch
    - 0022_fix_return_val_dump-resample-methods.patch
    - 0023_use_gdbm-nolock.patch
    - 0024_dont_mix_front-center_into_rear.patch
    - 0025_drop_cap-nice_properly.patch
    - 0027_handle_multicast_sdp_with_same_ip_ttl_as_rtp.patch
    - 0029_add_minor_fixes.patch
    - 0030_dont_drop_client_data.patch
    - 0031_use_fragsize_for_record_stream_latency.patch
  * Bumped shlibs for libpulse0.
  * Package libpulsecore8 -> libpulsecore9.
  * Add libdbus-glib-1-dev to build-depends.
  * Regression fix:
    - pulse.conf: Always honour ~/.asoundrc and /etc/asound.conf with highest
      priority, thanks to Daniel T Chen. (LP: #295832)

pulseaudio (0.9.13-2ubuntu7) UNRELEASED; urgency=low

  * Add fixes from 0.9.14:
    - 0030_dont_drop_client_data.patch,
    - 0031_use_fragsize_for_record_stream_latency.patch,
    - 0032_fix_suspend_sinks_sources.patch (LP: #317613)

 -- Luke Yelavich <email address hidden> Mon, 19 Jan 2009 14:45:36 +1100

Changed in pulseaudio:
status: Fix Committed → Fix Released
Martin Pitt (pitti) wrote :

Uploaded.

Changed in pulseaudio:
status: New → In Progress
Martin Pitt (pitti) wrote :

Accepted into intrepid-proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in pulseaudio:
status: In Progress → Fix Committed
Martin Stjernholm (msub) wrote :

Verified that 0.9.10-2ubuntu9.3 fixes my problem.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package pulseaudio - 0.9.10-2ubuntu9.3

---------------
pulseaudio (0.9.10-2ubuntu9.3) intrepid-proposed; urgency=low

  * Regression fix:
    - pulse.conf: Always honour ~/.asoundrc with highest
      priority (LP: #295832).

 -- Daniel T Chen <email address hidden> Sun, 18 Jan 2009 15:04:21 -0500

Changed in pulseaudio:
status: Fix Committed → Fix Released
vitaminmoo (vitaminmoo) wrote :

This appears to be back on 12.04.1 in the pulseaudio-1.1-0ubuntu15.1 package. As far as I can tell, the exact same patch used previously can fix it.

I can confirm and reproduce this bug once again. I came here after I attempted to override pcm.!default in my user-level configuration through .asoundrc.
I could not understand why it did not work until I typed in `aplay -L' to see that /usr/share/alsa/pulse-alsa.conf was overwriting it based on the description.

Guru Prasad (guru2411) wrote :

This bug exists in Ubuntu 14.04.

I created ~/.asoundrc and attempted to override pcm.!default which was not honoured by ALSA due to /usr/share/alsa/alsa.conf.d/pulse.conf running after /usr/share/alsa/alsa.conf. This caused pulse to override my defaults.

An easy fix so far seems to be including ~/.asoundrc in /usr/share/alsa/alsa.conf.d/pulse.conf.

Rafael Rubio (rafa-rubio-s) wrote :

This bug isn't fixed already, in 17.10 version I must edit /usr/share/alsa/alsa.conf.d/pulse.conf and add the asound.conf and .asoundrc. I have a JAVA app that uses alsa to redirec its audio to a fifo and I have to make this changes every time ALSA is updated. Please, reopen the bug or give an alternate solution that doesn't imply editing this file.

Daniel van Vugt (vanvugt) wrote :

This bug is closed, rightly or wrongly. I'm not saying the fix mentioned above was really sufficient, but since it was declared closed 8 years ago it would be most helpful for anyone still experiencing problems to open a new bug with fresh information using this command:

  ubuntu-bug pulseaudio

Thanks.

Daniel van Vugt (vanvugt) wrote :

* Declared closed over 9 years ago.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers