Can't use other than default sound card

This is still a problem and could be a big issue if it is not resolved before dapper is released.

The problem appears to have worsened. I can't use any of my sound cards now.

Correction, it's not that it's worse, but that if you don't use alsaconf to configure a default sound card it will not know what "default" is either.

Try deleting .asoundrc* and then launch Ekiga.

can you provide a few more details? such as kernel version and ubuntu version (i asume dapper?)
Are you sure its an ekiga problem - do you get these sound issues with any other applications?

I'm using dapper, updated daily. The problem may not be precisely an Ekiga problem. It looks like what's happened is that the alsa configuration on dapper no longer has all of the device aliases it used to have. So for instance if you select the 2nd sound card (or even the first! anything other than "Default") Ekiga will try to open plughw:2. This "device" used to exists in older versions of alsa (or non-Ubuntu versions?) but doesn't exist after alsa was updated a while back.

I logged it as an Ekiga bug because it seemed to me that the Alsa changes were probably intentional and applications needed to be updated to "the new way" in order to work properly.

See the log output included in the bug description.

This is an alsa-lib bug, not an ekiga bug.

My bug was just marked as a duplicate of this one. Indeed, it is not a ekiga bug. It is a alsa package configuration bug. Anything that needs to access the card(s) via the definitions that can't be found will be affected. Jackd is, for instance. All packages that require jack are therefore unusable. I understand that alsaconf is a "hack" -- but a non-"hack" config tool needs to be written into the package config scripts or at least done by gnome/kde's sound config tools. otherwise dapper will be all but useless for any advanced sound projects, unless the end user is remarkably savvy.

I get this same error as in Bug#33903. Removing my ~/.asoundrc* files DOES NOT WORK! I repeat, this does not work for me!

I then get this error.

loading driver ..
apparent rate = 44100
creating alsa driver ... hw:0|hw:0|1024|2|44100|1|1|nomon|swmeter|-|16bit
control device hw:0
configuring for 44100Hz, period = 1024 frames, buffer = 2 periods
ALSA: cannot set channel count to 1 for capture
ALSA: cannot configure capture channel
cannot load driver module alsa
10:48:56.975 JACK was stopped successfully.
10:48:58.920 Could not connect to JACK server as client. Please check the messages window for more info.
10:57:47.195 Startup script...
10:57:47.195 artsshell -q terminate
can't create mcop directory
Creating link /home/ethan/.kde/socket-zaphire.
10:57:47.466 Startup script terminated with exit status=256.
10:57:47.466 JACK is starting...
10:57:47.466 /usr/bin/jackd -R -dalsa -r44100 -p1024 -n2 -D -Chw:0,1 -Phw:0,2 -S -i1 -o1
10:57:47.475 JACK was started with PID=6797 (0x1a8d).
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 = 44100
creating alsa driver ... hw:0,2|hw:0,1|1024|2|44100|1|1|nomon|swmeter|-|16bit
control device hw:0
configuring for 44100Hz, period = 1024 frames, buffer = 2 periods
ALSA: cannot set channel count to 1 for capture
ALSA: cannot configure capture channel
cannot load driver module alsa
10:57:47.500 JACK was stopped successfully.
10:57:49.488 Could not connect to JACK server as client. Please check the messages window for more info.

(It seems that removing .asoundrc* helped hydrogen use alsa though!)
I really need to get this working!

In Dapper Drake flight 6, running winecfg and
clicking on the audio tab crashes with
"can't create mcop directory". The workaround is:
  mkdir -p $HOME/.kde/socket-`hostname`
This has been posted many times, e.g.
http://www.ubuntuforums.org/showpost.php?s=458b6a734e70e0c6e4d8dd998e7b1693&p=846489&postcount=129

See also a similar bug in other distros, e.g.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169631

Ethan, you need to post your jackd invocation command.

Everyone else-- please do not add unrelated information to this bug report. Instead, file separate reports, thanks.

Speaking of related information, if alsamixer is run without any arguments it fails (where it used to pick up the default sound card). This seems related.

$ alsamixer
ALSA lib confmisc.c:1107:(snd_func_refer) Unable to find definition 'defaults.ctl.card'
ALSA lib conf.c:3493:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib confmisc.c:242:(snd_func_getenv) error evaluating default
ALSA lib conf.c:3493:(_snd_config_evaluate) function snd_func_getenv returned error: No such file or directory
ALSA lib conf.c:3962:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib control.c:817:(snd_ctl_open_noupdate) Invalid CTL default

alsamixer: function snd_ctl_open failed for default: No such file or directory

Andrew, this last issue you've posted is known: bug #33420.

Guys, is this issue still viable on current Dapper with the latest kernel and gnome-{control-center,volume-manager} uploads?

> Guys, is this issue still viable on current Dapper with the latest kernel and gnome-{control-center,volume-manager} uploads?

I don't know what gnome-volume-manager, etc. has to do with it but the issue still exists and is, in my opinion, very serious.

Is this distinct from bug #35540? It sounds quite similar.

> Is this distinct from bug #35540? It sounds quite similar.

No, the fix for that bug has been released and works fine. This bug is still present. I mentioned above that I wondered if they were related but Daniel pointed out that they are not.

I guess this is a bug that you will only see if you have more than one sound card. In my case the second sound card is a USB phone which I want to be able to use with Ekiga while leaving the PCI sound card as the default for all other applications. The bug doesn't exist on other distros that I've tried.

Actually now that I mention it you should be able to see the bug if you select your sound card by name rather than "Default" in Ekiga's Preferences dialogs. Run the First Time Configuration Assistant "Edit->Configuration Druid" and skip through to the page where you select which audio devices to use. Select your sound card (not "Default", even though they are presumably the same thing) and then hit "Test Settings." You should be given an error dialog saying that something might be wrong with permissions or something. On the console you'll get the same output as in the original report.

I've noticed that sometimes it works (or looks like it's going to work) but if you go back and try it again it will fail.

Please let me know what I can do to help diagnose this problem, this bug is very important to me. It sounds like something is just missing from the alsa config files or something.

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
...

I can confirm that Daniel's fix works for me at least. I'm very happy about that! On the other hand I'm a little disappointed because part of the why we wanted to do this asoundrc trick was so that we could select the default device by name, not by number (which in the case of USB devices doesn't always stay the same). I wonder if there's some configuration trick that can be used to set these device numbers off the names rather than hardcoding them in .asoundrc*. Alsa's config files are rediculously complex, so it's possible there is a way.

All in all though I'm very pleased and in my case this is going to work just fine. Thanks Daniel, you're my hero!

- Andrew

On Fri, May 05, 2006 at 02:54:53AM -0000, Andrew Jorgensen wrote:
> I can confirm that Daniel's fix works for me at least. I'm very happy about that! On the other hand I'm a little disappointed because part of the why we wanted to do this asoundrc trick was so that we could select the default device by name, not by number (which in the case of USB devices doesn't always stay the same). I wonder if there's some configuration trick that can be used to set these device numbers off the names rather than hardcoding them in .asoundrc*. Alsa's config files are rediculously complex, so it's possible there is a way.

Actually it's even better than what you describe. After returning home,
plugging in my external USB sound device, and testing, I've narrowed
the necessary modifications against current alsa-utils to the
following:

(1) ~/.asoundrc.asoundconf needs to contain the following:

defaults.pcm.device 0
defaults.pcm.subdevice -1

That's right, neither of those values will ever have to change! I had
overlooked that !defaults overrides defaults, so all gnome-control-
center needs to do via set_default_card() is change the values for
defaults.pcm.card and defaults.ctl.card as it's currently doing. As
long as defaults.pcm.device and defaults.pcm.subdevice are defined in
~/.asoundrc.asoundconf, we can override the card with
!defaults.pcm.card as we're currently doing.

(2) defaults.ctl.card should be changed by set_default_card(), but it
should not override ALSA's default. That is, our current rationale for
using ! for strings, which forces "!defaults.ctl.card ICH6" instead of
"defaults.ctl.card ICH6" as it should be, is incorrect. I noticed this
symptom when testing ogg123 and aplay with the new set of asoundrc
variables that I stated in the last e-mail, which results in errors of
not being able to find defaults.pcm.card and thus bailing.

So, to recap: We need to hard-code "defaults.pcm.device 0" and
"defaults.pcm.subdevice -1" in ~/.asoundrc.asoundconf. We also need to
strip the leading ! from defaults.ctl.card. With this modification,
amixer, aplay, ogg123, gst*, and jackd all play nicely. Better yet, we
retain dmix by default [0]. :)

(Apologies for the noise across five different Malone bug reports.)

[0] Well, save for USB devices, but that's a known issue in alsa-lib.
    See Malone #33736.

Thanks,
--
Daniel T. Chen <email address hidden>
GPG key: www.sh.nu/~crimsun/pubkey.gpg.asc

Daniel, thanks a lot for your detailled explanation. This requires some more changes, asoundconf currently always uses a '!' for strings, so I should teach it not to, and instead specify the ! in the argument given to it.

Actual configuration changes have to happen in control-center.

If those changes are never going to change, shouldn't they be in the global configuration rather than in .asoundrc.aoundconf? Or will they break something if !defaults.pcm.card and !defaults.ctl.card are not set?

On Fri, May 05, 2006 at 02:34:15PM -0000, Andrew Jorgensen wrote:
> If those changes are never going to change, shouldn't they be in the
> global configuration rather than in .asoundrc.aoundconf? Or will they
> break something if !defaults.pcm.card and !defaults.ctl.card are not
> set?

Those variables are already in the global configuration file(s) [0],
but the presence of ~/.asoundrc overrides them. So yes,
!defaults.pcm.card, defaults.ctl.card, defaults.pcm.device, and
defaults.pcm.subdevice should always be specified given our usage.

[0] /usr/share/alsa/alsa.conf

Thanks,
--
Daniel T. Chen <email address hidden>
GPG key: www.sh.nu/~crimsun/pubkey.gpg.asc

I alsa filed a duplicate of this bug (bug 42214). The mail sent out recently by Mr. Chen was very extensive and seems to provide a solution to the problems. I'd be very grateful if this could soon be resolved. Thanks to Mr. Chen for explaining the situation so expertly.

I now have two problems:
1) I cannot hear any sound outputted through ALSA with the Audigy2 card.
2) I have set the values as Mr. Chen suggested. However, if I strip the "!" from defaults.ctl.card, I get errors:
ALSA lib conf.c:1592:(snd_config_load1) /home/toby/.asoundrc.asoundconf:8:0:Invalid argument
ALSA lib conf.c:2837:(snd_config_hook_load) /home/toby/.asoundrc may be old or corrupted: consider to remove or fix it
ALSA lib conf.c:2700:(snd_config_hooks_call) function snd_config_hook_load returned error: Invalid argument
ALSA lib conf.c:3066:(snd_config_update_r) hooks failed, removing configuration
amixer: Mixer attach hw:1 error: Invalid argument
ALSA lib conf.c:974:(parse_value) card is not a string

Regarding point 1).
I cannot hear the "sound outputted through ALSA with the Audigy2 card" as the system still seems to route it to the ICH6. You can probably tell, also, that I have two cards; an ICH6 (0) and an Audigy2 (1).

Now, I have it working so that sound comes through the Audigy, with these values:
!defaults.pcm.card Audigy2
defaults.ctl.card Audigy2
defaults.pcm.device 0
defaults.pcm.subdevice -1

However, the Master channel no longer seems to affect the output volume. I have to use PCM instead. It's no bother, I'm just curious. The issue where the Audigy2 was outputting no sound seems to have fixed by me completely reconfiguring ALSA, so it's safe to say that it can be ignored, I think.

@.t.: Yes, the values that you currently have in ~/.asoundrc.asoundconf are correct for a multi-card configuration. It is essentially identical to what I tested and described above, save I have USB for the string. Martin's making the necessary changes to gnome-control-center (and alsa-utils).

That's very good. Send him my thanks.

On 06/05/06, Daniel T Chen <email address hidden> wrote:
>
> @.t.: Yes, the values that you currently have in ~/.asoundrc.asoundconf
> are correct for a multi-card configuration. It is essentially identical
> to what I tested and described above, save I have USB for the string.
> Martin's making the necessary changes to gnome-control-center (and alsa-
> utils).
>
> --
> Can't use other than default sound card
> https://launchpad.net/bugs/31699
>

g-v-m needs to be adapted as well for handling the removal of the default sound device.

 alsa-utils (1.0.10-1ubuntu10) dapper; urgency=low
 .
   * debian/asoundconf:
     - Remove the automatic prepending of '!' for non-numeric parameter values;
       this approach is flawed (see lengthy explanation in LP#31699).
     - Add two convenience functions set-default-card and reset-default-card
       which care for the correct handling of !defaults.pcm.card,
       defaults.ctl.card, defaults.pcm.device, and defaults.pcm.subdevice.
       Doing it here in python is way easier and less error prone than handling
       this in C in control-center. Closes: LP#31699
   * debian/asoundconf.1: Describe set-default-card and reset-default-card.

 control-center (1:2.14.1-0ubuntu7) dapper; urgency=low
 .
   * debian/patches/23_default_soundcard_selector.patch:
     - Use new asoundconf's set-default-card command instead of setting the set
       of required parameters ourselves. Closes: LP#31699
   * debian/control.in: Depend on alsa-utils >= 1.0.10-1ubuntu10 which provides
     set-default-card.

 gnome-volume-manager (1.5.15-0ubuntu8) dapper; urgency=low
 .
   * debian/patches/91_ubuntu-remove_default_audio_dev.patch:
     - Use asoundconf reset-sound-card instead of manually resetting the
       various parameters.
     - Closes: LP#31699

> - Use asoundconf reset-sound-card instead of manually resetting the

This should be reset-default-card, of course. The code is correct, just the changelog is wrong. Will fix in next upload.

Maybe in general bug is solved, but I have run into two errors again:

* Can't record anything with arecord -Dhw:0, plug:hw:0 works. Recording with former (hw:0) gives such error:
pecisk@ubuntu:~$ arecord -D hw:0 --rate=48000 -c 2 test.wav
Recording WAVE 'test.wav' : Unsigned 8 bit, Rate 48000 Hz, Stereo
arecord: set_params:896: Sample format non available

* My Terratech EWS88MT (ice1712 chipset) sound card plays all music in the way lower frequency as it should do it (Feels like 22000), as it comes out slower. Movies does just fine. It certainly could be different issue, bet where to fill it then?

Post scriptum for comment above: --rate=48000 is just for example, for this card such rate is aviable, it gives the same error with -f cd or --rate=44000 too, so there is no difference.

Pecisk, I doubt that this is any other issue than that your device does not support the S16_LE, nor the U8 sample format. See the -f, --format option in the arecord manpage. I don't recall at the moment how to determine which formats a particular card supports but there are a great many formats to choose from.

After googling a little I think the correct format for your card is S32_LE. Try the same command you did before except with -f S32_LE and let us know if it works. If that doesn't help please open a new bug report.