After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 172594 - Handling of USB soundcards and soundcards above 1
Handling of USB soundcards and soundcards above 1
Status: RESOLVED DUPLICATE of bug 329112
Product: gnome-media
Classification: Deprecated
Component: gstreamer-properties
2.10.x
Other All
: Normal normal
: ---
Assigned To: gnome media maintainers
gnome media maintainers
Depends on: 141449 172161 172333
Blocks:
 
 
Reported: 2005-04-04 10:15 UTC by Christian Fredrik Kalager Schaller
Modified: 2006-01-30 12:37 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10



Description Christian Fredrik Kalager Schaller 2005-04-04 10:15:15 UTC
Please describe the problem:
I am opening this bug to see if we can find some agreement on where to add what
in terms of getting external soundcards working well under GNOME.

There are multiple systems which needs to be able to handle this, including
ALSA, OSS, HAL, and GStreamer (and probably some I forget).

Question is what needs to happen when you plug in an USB soundcard and who is
responsible for handling it. I take my own USB soundcard as an example of
challenges that needs handling.

Lets start with describing what I think needs to happen, then follow on with my
ideas on implementation. The most major item is getting a dialog appearing which
asks you if you want to switch sound output to the new device and when you have
choosen your new output all GNOME applications should use this unless they
explisitly ask for something else. When the USB device is disconnected it should
automatically revert to the former settings.

For my hardware (Sound Blaster Audigy2 NX) the system also needs to set up
automatic sound conversion to 48000 instead of default 44100 or the sound gets
badly distorted (at least it does so when using the spdif output). It also needs
its speaker output unmuted.

So question what is needed where to make this work. Currently in gnome-media we
install a couple of gconf keys which stores which output sink to use for audio
and video. But I guess we need more keys added to also store information about
which hardware to use with each sink (not only for USB, but also if you have
two/three PCI soundcards for some reason). These keys should if possible be
generic between soundsystems (OSS, ALSA, Sun Audio etc.).

GStreamer can do the rate conversion, but I guess this should be done at the
ALSA/OSS level? (which I guess its needs to be done by HAL). (Or will audio
people get angry if we mess with their output rates at the ALSA level?)

Are soundcard specfic 'profiles' needed? If so, then if we can agree upon what
kind of information needs to be collected for each card I can go about doing that.

I guess the sound capplet should be extended to let you choose default
soundcard. (In case you want to switch back, or switch between soundcards).
Useful for both USB and multiple PCI soundcard setups. These config dialogs
should ideally only be shown I guess if there actually is more than one soundcard.

The GNOME mixer tend to not adjust the correct slider to get sound in many
cases. Can HAL help with this? ie. let gnome-mixer know that this is a sound
card of type XY so you need to adjust this or that slider to adjust sound.

This are just my initial thoughts. Parts of the reason for opening this bug is
also to let the people involved have a common place to agree upon what belongs
where. I mean what should be added to GStreamer, gnome-media, HAL etc.

I am cc'ing David and Colin on this bug.

Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Ronald Bultje 2005-04-04 10:40:53 UTC
My ideas, in no specific order:

Audigy support / general issues:
* if you want me to be of any good help, get me such a soundcard
* the sound distortion is because ALSA claims it supports 44,1 kHz (hw:X),
although it really doesn't (I've had a Audigy 2 NX a while ago for testing);
ALSA bug
* sound unmuting should be done while configuring the device; distro task, or
ALSA bug (if you consider the default mute behaviour broken, which I do)
* we indeed show the wrong speaker slider, gnome-media bug
* the multimedia selector doesn't show devices, there's already a bug report for
this

On the hardware refresh:
* hardware notifications are a HAL task
* stuff like gnome should listen for such notifications and update when new
hardware is added
* gnome-media is not the place for general desktop event listening; I think
gnome-settings daemon or another general GNOME daemon (it handles multimedia
keys, too) is more appropriate
* the mixer currently doesn't share the sound output with apps such as RB/Totem;
I'm not sure it should, maybe it should, maybe not
* playbin + gconfaudiosink will do auto-refresh-on-the-fly if the gconf key
changes; however, totm/RB don't use this yet; they use a custom function.
Application bugs (not very weird; gconfaudiosink is only available in our latest
release or maybe even CVS-only).
* maybe we need a gconfmixer bin in GStreamer?

More general stuff:
* this is a lot of work. You cannot expect someone to do this alone. If vendors
are interested, pay someone. Else, do it yourself. It's too much for me, givent
hat I need to finish studies, work and don't have the hardware.
Comment 2 Steve Coffman 2005-04-13 14:47:40 UTC
If Ronald is in the US again I'd be happy to loan him my sound card again for a
couple months like when he was working on multichannel support in gstreamer, or
someone he recommends as trustworthy. Can't help him with his studies or work
though. :)

I added dependencies on existing relevant GNOME bugs, but couldn't locate "the
multimedia selector doesn't show devices, there's already a bug report for this"
as referenced above. I haven't added the new bugs as suggested above either.

I filed a related HAL Bug at https://bugs.freedesktop.org/show_bug.cgi?id=3011 

Related Redhat Bug (removed USB sound card, reinserted, new address)
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=153064

Related Redhat Bug (removed USB Audigy NX2 sound card causes keyboard to stop
working):
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152952
Comment 3 Ronald Bultje 2005-04-13 14:55:36 UTC
The "show devices" bug is 141449.
Comment 4 Steve Coffman 2005-04-13 15:28:09 UTC
Cool. Added the show devices bug as a dependency.

Logged ALSA bugs on the distortion:
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1050

Ok, back to my day job.
Comment 5 Steve Coffman 2005-06-24 14:55:16 UTC
ALSA bug #1050 has been fixed in 1.0.9
Comment 6 Christian Fredrik Kalager Schaller 2005-07-22 12:01:20 UTC
Bastien wrote a nice summary of the topic with some usecase samples and posted it
to the utopia list. Adding a link to it here for completeness.

http://mail.gnome.org/archives/utopia-list/2005-July/msg00001.html
Comment 7 Ralph Giles 2005-08-16 19:33:09 UTC
Pretty much what Ronald said, but additional "me too":

I don't like the idea of a dialog on insert. With something like a usb audio
device, it is probably reasonable to assume that if the user has plugged it in,
that they intend to use it, and autoswitch, just the way on a laptop speakers
are automatically muted when something is plugged into the headphone jack. (ALSA
bugs notwithstanding.) Output should autoswitch back to the previous config if
the device is removed.

Different preferences could of course be set in a capplet, as a more
sophisticated user with multiple soundcards will want to do.

Ideally, something like the gnome-settings daemon should maintain a preference
list so that hotplug devices that have been seen before are remembered and it is
always the highest priority device that is used for playback, with ordered
fallback should that device be removed. Initial priority for new devices could
be set either with Christian's prompt-on-insert, or default to highest as I've
suggested.
Comment 8 Gord Wait 2005-10-11 18:40:16 UTC
You can't assume either case is a 100% solution. I'd suggest that the decision
to move the "audio focus" from one sound output to another is a configurable
item, and the first time a user plugs in a USB audio device, this applet does
pop up and ask what should be done, with the option to remember the choice
permanently. 

At the application configuration level, why not show a new virtual audio device
called say the "current audio device" which is the audio device that represents
the auto switching audio, along with the traditional harware selections. The
"current audio device" would be the one that changes to the new usb audio widget
when it's plugged in, and revert back to the previous one when the usb one is
unplugged. 
Users could then select what to do on an application by application basis. 
Perhaps this is more of a task for Alsa?
Comment 9 Christian Fredrik Kalager Schaller 2006-01-30 12:37:16 UTC

*** This bug has been marked as a duplicate of 329112 ***