Version: 4.1.68-svn 2008-10-09 (using Devel) Compiler: gcc (Gentoo 4.3.1-r1 p1.1) 4.3.1 OS: Linux Installed from: Compiled sources The default device of ALSA is not listed in device list when Xine backend is used.
As mentioned by someone on IRC... I need a reason for this, ehkn, so it follows: ALSA default device is the default for all ALSA applications. It is also the most often overridden device in asound.conf and ALSA configuration. (my example is equalizer attached to it) Not using the device bypasses most of ALSA configuration.
If you are able to edit your ~/.asoundrc then you should also be able to follow the instructions on phonon.kde.org how to make a specific entry appear for Phonon to use. :) Anyway, the reason the "default" device is not used by Phonon is that there's no way to know for the system what actual device this is going to access. As the Phonon device configuration is centered around actual devices "default" is useless. And showing "default" to the average user is also not a good idea, especially since on all the default Distro installations "default" can change depending on the order the sound devices are registered. It's sad to see all non-Phonon applications playing to the wrong device then. :(
I think what this user is requesting is that if the user has configured the default device in to point to s specific device then phonon should use that setting. For example in my /etc/asound.conf I have: pcm.spdifdmix { type dmix ipc_key 1024 slave { pcm "hw:0,1" format S32_LE period_time 0 period_size 1024 buffer_size 8192 } } pcm.duplex { type asym playback.pcm "spdifdmix" capture.pcm "dsnoop" } default ALSA route for software support of multiple sound streams pcm.!default { type plug slave.pcm "duplex" hint { show on description "default device spdif" } } This says that default is pcm "hw:0,1" which is the s/pdif outputs for my card. All of the other software on my system uses this settings and I get output on my s/pdif output from all of these apps without having to do anything else. In the System Settings -> Sound dialog CARD=0,DEV=1 is not even listed unless I turn on "Show Advanced Devices" or I add a hint to the default section of /etc/asound.conf. So phonon not only ignores my explicitly setup configuration for the default device but does not even list the device that I want to use by default as an option without doing additional setup work. Your argument for not using the default device makes sense on systems that have not been configured to specify a specific default device but for systems where the user has configured ALSA to specify the default device this is not a valid argument. In other words when the ALSA configuration does specify what physical device is the default device then that device should be the normal default device in phonon unless the user explicitly over rides that settings.
Alright, now plug in two USB audio devices (at least that's what's required on my Kubuntu system) and card 0 might be one of those USB devices on reboot => hw:0,1 might be non-existent... that was one of my arguments that you didn't counter. I agree with you that if you configured your device with ~/.asoundrc, you want applications to follow that. All extra steps required to get there seem unnecessary and unintuitive (not that ~/.asoundrc is intuitive... :) ). But I don't know of any way to determine for sure that the user wants to use "default". The only sure thing is if he adds a hint+name and selects that in the Phonon device configuration. About 0,1 not showing: the ALSA names for those devices are often "Foo Analog" for 0,0 and "Foo Digital" for 0,1. Guess what clueless users will select and then ask why it doesn't work. I put it into the advanced devices because most users have no idea what S/PDIF is, how to use it, or whatever. So better hide it. People how know about audio stuff will have no fear to tick the "Show Advanced Devices" box. If you have a better idea how to make this work for both kinds of users let me know. I'm not overly happy with the current solution.
"Alright, now plug in two USB audio devices..." Yes that is a somewhat more difficult case but isn't that what udev is for? There is a wiki page on the alsa site that covers this http://alsa.opensrc.org/index.php/Udev . With udev you can control the naming of the usb sound devices so that there will always be the same naming (meaning hw:x,y) for a particular piece of physical hardware regardless of the order in which these are plugged in and when they are plugged in. I know this is not any easy issue to deal with and many users will have no idea how to use udev to make things work correctly or for that matter even know that udev is the correct answer. Then there is the UI (really lack of UI) issue with regard to udev. It really needs a nice end user accessible UI so that users can do things like setup multiple sound cards without having to use a text editor and perhaps that UI would even have some built in error checking so that even naive users stand a chance of getting it to work. Having worked on complex apps I know that many times these UI issues are the most difficult part of the application to design (and also the area where the developers get the most grief from users) and this is particularly true when your app has complex interactions with external systems and hardware like yours does. Its a difficult job and there are no easy answers. You are also correct about how naive many users are. I work on apps that are very technical in nature where I would expect the users to have a certain level of domain knowledge. For these apps I should be able to get away with doing things like using domain specific technical terminology in the apps UI. Even under those circumstances users still complain about the UI being hard to understand (IE. I don't know what "colorimetric" or "gamut" or "gamma" means could you explain that?). Since your UI is used by a much wider range of users including some who are complete noobs this makes it more of a challenge since it needs to "just work" for users who have no idea what they are doing. Again there are no easy answers. Hopefully as phonon matures so will the UI.
There are also other ways to specify the order of devices, for example with module options, although with USB devices, it doesn't work nicely. Udev needs some UI. :) What's more important, only KDE was misbehaving. All other applications use the default device by default (duh). If it's broken, it's user's or distro's fault. (Will Xine device numbers be stable if ALSA devices change? I don't think so.) Phonon could configure asoundrc default device for you, but that's an entirely another request, tangential to the issue. The more pressing concern is that you can't pick any ALSA device, except hardware cards. It should list them at least as advanced devices, otherwise it's a huge lack of feature: If I want to use 5.1 matrixing, no, it won't let me. 2 speakers only for me. If I want to add a general eq, tough luck. If I want to drop sound to a file, uh oh... I instead have to use some workaround in the form of Pulseaudio. (nice workaround, but still...)
What's so hard about adding a hint section? Everything you describe needs a user capable of editing his ~/.asoundrc. That's probably less than 1% of the Linux users... What do you mean with Xine device numbers? (K)ubuntu uses module options to try to make the non-USB soundcard card number 0. But that doesn't work correctly. Udev might be the way to go, but from what I read it's currently impossible to create a general setup, and creating a UI for it is out of Phonon's scope. Pulse and Jack also don't default to the ALSA "default" device. For good reasons. Phonon has good reasons too. Letting the Phonon configuration overwrite ~/.asoundrc is problematic, though I did consider it and still didn't fully discard the idea. That devices defined in ~/.asoundrc need a hint section is something libasound requires, not Phonon. I could write a ~/.asoundrc parser, but that'd be just asking for trouble.
Hmm, ok then. I still wouldn't drop the default device even if it has no hint, but it's your call. Consider the discussion finished.
I followed by instruction on phonon.kde.org how to make a specific entry appear for Phonon to use. (My asound.conf is in attachment.) The problem is after logout my custom sound device(described in hint section) sometimes became inactive/disabled, phonon says "Device is inactive" and can be removed from list of sound devices.So i need login/logout few times to make it work.It's phonon or alsa bug? alsa-1.0.19, kde-4.2.0 Gentoo
Created attachment 30729 [details] asound.conf
Ivan: that looks strange. Phonon asks that question when it can't find the device in the ALSA config anymore (e.g. it should come up when you delete a device definition with hint section from asoundrc). But you only restarted... Or am I misunderstanding your description and it's not asking you, but only showing it in the config dialog as disabled and removable? In that case the problem is that it tried to open the device and ALSA said it doesn't work (probably blocked by another process having it open with an incompatible dmix ipc_key or so). I'm not sure how to properly handle this one. Perhaps the code needs to be more forgiving: if a device doesn't open, doesn't mean it doesn't always work... but really it shows some misconfiguration/misuse of the ALSA layer. Try setting the dmix ipc stuff to this: ipc_key { @func refer name defaults.pcm.ipc_key } ipc_key_add_uid false ipc_gid { @func refer name defaults.pcm.ipc_gid } ipc_perm { @func refer name defaults.pcm.ipc_perm }
Matthias: I'd tried this code(with ipc stuff), but it doesn't help. First time login it works normaly, after relogin it says Onboard soundcard doesn't work, and in the Multimedia options it shows in grey color, all other devices in list are green and works. If I comment out in asound.conf section with hint than save file-I see an popup window message that Onboard soundcard was removed, after uncommenting hint section, it shows in popup that device were added and there 50/50 chances it begin work. Sorry for my poor English.