Bug 230069 - Ekiga should use the "default" ALSA device
Summary: Ekiga should use the "default" ALSA device
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: ekiga   
(Show other bugs)
Version: 6
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Daniel Veillard
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-02-26 14:04 UTC by Steve Hill
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-13 13:48:40 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Strace of aplay attempting to use plughw:1 (7.54 KB, text/plain)
2007-02-26 14:04 UTC, Steve Hill
no flags Details

Description Steve Hill 2007-02-26 14:04:14 UTC
Description of problem:
I have a system with 2 sound cards:
Card 0: emu10k (SB Live Value)
Card 1: intel8x0 (nForce integrated sound device)

system-config-soundcard creates a /etc/asound.conf like:
  #Generated by system-config-soundcard, do not edit by hand
  #SWCONF
  #DEV 3
  defaults.pcm.card 0 
  defaults.pcm.device 3 
  defaults.ctl.card 0 
This works fine for card 0, but accessing "plughw:1" (Ekiga does this) causes
alsa to try and open /dev/snd/pcmC1D3p (card 1, device 3) which does not exist.
 Setting defaults.pcm.device to 0 manually solves the problem.

I'm not that familiar with the workings of ALSA, but it seems that
defaults.pcm.device is applied to both cards, but is only really relevent to the
default card.  Each card should probably have it's own default device setting?

Version-Release number of selected component (if applicable):
system-config-soundcard-2.0.5-2.fc6

Steps to Reproduce:
1. Set up FC6 on a machine with both an emu10k and intel8x0 card
2. Try opening the "plughw:1" ALSA device
  
Actual results:
"aplay -D plughw:1 sound-sample.wav" fails to open the device (see attached strace)

Expected results:
Above commandline should successfully open sound card 1.

Additional info:
For some reason, default:1 seems to work, even though plughw:1 does not.

Comment 1 Steve Hill 2007-02-26 14:04:14 UTC
Created attachment 148792 [details]
Strace of aplay attempting to use plughw:1

Comment 2 Martin Stransky 2007-03-08 09:38:11 UTC
Aha, I'll check it. Thanks for the report.

Comment 3 Martin Stransky 2007-04-11 09:07:48 UTC
It isn't a bug in ALSA. All applications should use the "default" sound device,
not plughw. moved to ekiga.

Comment 4 Daniel Veillard 2007-07-13 13:48:40 UTC
I don't really understand. If you use the Ekiga configuration druid,
after having selected Alsa as the audio manager (page 6/10), in the
next page you can select, either the "default" or the individual
cards to use for audio input and output device. So the fact of
not using "default" is probably due to the device having been manually
selected at some point, and can be trivially fixed by rerunning the
druid (menu Edit > Configuration Druid), so I don't understand the problem.

If you still think there is a problem with Ekiga internals and not
about the specific configuration, please report this upstream:
  - bugzilla.gnome.org, module Ekiga

There is an ekiga developper mailing-list too 
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

For me this work, I can pick either the default as configured at the
Alsa level or the individual cards if I need to override.

Daniel

Comment 5 Steve Hill 2007-07-13 14:07:11 UTC
The problem is that Ekiga addresses individual devices as "plughw:0",
"plughw:1", etc. when you select them from the drop-down list.  It should be
using "default:0", "default:1", etc.

Unfortunately, even though the ALSA people agree with me, the upstream Ekiga
developers are convinced that what they are doing is correct, so there's a bit
of a stalemate situation. :(

Comment 6 Daniel Veillard 2007-07-13 14:25:14 UTC
Hum, okay. Honnestly I don't think it's worth trying to patch ekiga in our 
release, I don't feel like it's a good place to raise/fix problem with upstream
decisions. So I'm tempted to close as WONTFIX,

  opinion ?

Daniel

Comment 7 Steve Hill 2007-07-13 14:42:09 UTC
Ok.  Close it as WONTFIX for now.  If I get time (seems unlikely in the near
future :( ) I will look at the latest Ekiga code and see if it's still doing the
same thing - if so I'll poke some people upstream.  I understand Ekiga is going
to be getting some major reworking done for the next release anyway.

Thanks.

Comment 8 Daniel Veillard 2007-07-13 15:11:09 UTC
Yeah 3.0 will have an awful lot of changes. Best will be to check again with
Damien when back from vacations,

  thanks,

Daniel


Note You need to log in before you can comment on or make changes to this bug.