asoundconf causes disruption to programs that expect other defaults in ALSA config files

Bug #42214 reported by Toby Smithe
10
Affects Status Importance Assigned to Milestone
alsa-utils (Ubuntu)
New
Medium
Unassigned

Bug Description

I have deduced that when using alsaconf, some programs are looking for definitions in ~/.asoundrc.asoundconf that aren't there. This includes, for example, defaults.pcm.subdevice, or, even hw:1. I have had trouble with many applications' sound, and will post the JACK std-out (captured through the qjackctl) for two situations as an example:
1) with ~/.asoundrc.asoundconf included in ~/.asoundrc
2) without.

I have no other definitions in ~/.asoundrc, but without the inclusion of ~/.asoundrc.asoundconf, I am unable to select a default sound card in the gnome-control-center applet. This is an important feature for me, say when I want to use my Audigy2, as opposed to my internal speakers with the ICH6. I assume that this is because that setting is a front-end to asoundconf.

For situation 1, the output is this:
09:49:36.569 Startup script...
09:49:36.569 artsshell -q terminate
can't create mcop directory
Link points to "/tmp/ksocket-toby"
09:49:39.503 Startup script terminated with exit status=256.
09:49:39.503 JACK is starting...
09:49:39.504 /usr/bin/jackd -R -u -dalsa -r96000 -p1024 -n2 -D -Chw:1,2 -Phw:1,3 -s -H -M
09:49:39.517 JACK was started with PID=5401 (0x1519).
jackd 0.100.0
Copyright 2001-2005 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK compiled with System V SHM support.
loading driver ..
apparent rate = 96000
creating alsa driver ... hw:1,3|hw:1,2|1024|2|96000|0|0|hwmon|hwmeter|soft-mode|32bit
control device hw:1
ALSA lib confmisc.c:1107:(snd_func_refer) Unable to find definition 'defaults.pcm.subdevice'
ALSA lib conf.c:3493:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:3951:(snd_config_expand) Args evaluate error: No such file or directory
ALSA lib pcm.c:2099:(snd_pcm_open_noupdate) Unknown PCM hw:1,3
ALSA lib confmisc.c:1107:(snd_func_refer) Unable to find definition 'defaults.pcm.subdevice'
ALSA lib conf.c:3493:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:3951:(snd_config_expand) Args evaluate error: No such file or directory
ALSA lib pcm.c:2099:(snd_pcm_open_noupdate) Unknown PCM hw:1,2
ALSA: Cannot open PCM device alsa_pcm for playback. Falling back to capture-only mode
cannot load driver module alsa
09:49:39.635 JACK was stopped successfully.

------
For situation 2:

09:52:08.396 Startup script...
09:52:08.396 artsshell -q terminate
can't create mcop directory
Creating link /home/toby/.kde/socket-leopard.
09:52:08.780 Startup script terminated with exit status=256.
09:52:08.780 JACK is starting...
09:52:08.780 /usr/bin/jackd -R -u -dalsa -r96000 -p1024 -n2 -D -Chw:1,2 -Phw:1,3 -s -H -M
09:52:08.791 JACK was started with PID=5510 (0x1586).
jackd 0.100.0
Copyright 2001-2005 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK compiled with System V SHM support.
loading driver ..
apparent rate = 96000
creating alsa driver ... hw:1,3|hw:1,2|1024|2|96000|0|0|hwmon|hwmeter|soft-mode|32bit
control device hw:1
configuring for 96000Hz, period = 1024 frames, buffer = 2 periods
Note: audio device hw:1,2 doesn't support a 32bit sample format so JACK will try a 24bit format instead
Note: audio device hw:1,2 doesn't support a 24bit sample format so JACK will try a 16bit format instead
nperiods = 2 for capture
Note: audio device hw:1,3 doesn't support a 32bit sample format so JACK will try a 24bit format instead
Note: audio device hw:1,3 doesn't support a 24bit sample format so JACK will try a 16bit format instead
nperiods = 2 for playback
09:52:10.809 Server configuration saved to "/home/toby/.jackdrc".
09:52:10.811 Statistics reset.
09:52:11.024 Client activated.
09:52:11.026 Audio connection change.
09:52:11.029 Audio connection graph change.
09:52:38.287 Client deactivated.
09:52:38.289 JACK is stopping...
jack main caught signal 15
no message buffer overruns
09:52:38.535 JACK was stopped successfully.

----

This shows that there is a difference in the reading of the configuration files when ~/.asoundrc.asoundconf is enabled, and that that file doesn't provide all the needed definitions, whereas /var/lib/alsa/asound.state does. Nevertheless, why isn't it reading /var/lib/alsa/asound.state after it has read ~/.asoundrc.asoundconf to get the correct definitions?

Revision history for this message
Daniel T Chen (crimsun) wrote : Malone #31699 (alsa-utils: asoundconf: gnome-control-center && default sound card)
Download full text (4.5 KiB)

Martin et al.,

I've done some further debugging for Malone #31699, and it appears that
the current fix for #35540 is insufficient (partially my fault). Some
applications expect defaults.pcm.device and defaults.pcm.subdevice,
which must be integers due to /usr/share/alsa/alsa.conf's use of
igetenv for .DEV and .SUBDEV. So to make all audio applications play
nicely together, we need to enumerate the following variables in
~/.asoundrc.asoundconf:

!defaults.pcm.card <string>
!defaults.ctl.card <string>
defaults.pcm.device <integer>
defaults.pcm.subdevice <integer>
[pcm.device <integer>]

Here's the breakdown: defaults.pcm.card and defaults.ctl.card can be
strings (as ``asoundconf list'', in which case the ! is required) or
integers (in which case the ! shouldn't appear). Currently gnome-
control-center sets these two variables, and most apps play nicely.
However, apps like jackd normally require a specific device (implying
that its subdevice must also be set), in which case defaults.pcm.device
and defaults.pcm.subdevice must also be set. The good news is that we
can get away with setting defaults.pcm.subdevice -1 (per definition in
/usr/share/alsa/alsa.conf) always, since apps will override it as
necessary.

I've currently been testing an ~/.asoundrc.asoundconf, and the above
variables for my current sound card configuration (only one on-board
Intel ICH6; the external USB M-Audio Transit is not present) are as
follows:

!defaults.pcm.card ICH6
!defaults.ctl.card ICH6
defaults.pcm.device 0
defaults.pcm.subdevice -1
pcm.device 1

so that I can use the on-board ICH6 by default and still use jackd with
either the onboard or the external usb sound device.

I've tested using both amixer and jackd with the above block (both with
and without pcm.device 1) as follows:

amixer && amixer -c0 && amixer -c1
jackd -d alsa && jackd -d alsa -dhw:0 && jackd -d alsa -dhw:1

The first two invocations of each program (i.e., amixer && amixer -c0
and jackd -d alsa && jackd -d alsa -dhw:0) work exactly as expected. I
am able to list the values of the mixer and successfully invoke jackd.
With pcm.device 1 present in ~/.asoundrc.asoundconf, I am able to
invoke the last set of each program (i.e., amixer -c1 and
jackd -d alsa -dhw:1) with the expected result that there is no such
device. I also receive identical results without pcm.device 1 present
in ~/.asoundrc.asoundconf.

The reason I mention additional "pcm.device"s is because of the
previously mentioned situation where a user may have multiple sound
cards detected and wish to have GNOME use a different default card from
say, jackd.

So, recap, and conclude with what we need to do to resolve #31699 and
its unfortunate duplicates:

At the very least ~/.asoundrc.asoundconf needs to have values for:

defaults.pcm.card
defaults.ctl.card
defaults.pcm.device
defaults.pcm.subdevice

I suggest we use the nominal default of -1 for defaults.pcm.subdevice,
continue using the strings for !defaults.{ctl,pcm}.card, and use an
integer for defaults.pcm.device. This means that gnome-control-center's
debian/patches/23_default_soundcard_selector.patch needs to be modified
such that set_default_card() also sets defaults.pcm.device and
...

Read more...

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.