Version: (using KDE KDE 3.4.0) Installed from: Debian testing/unstable Packages OS: Linux I got 3 sound cards in my system. One integrated, one at webcam (because of the mic) and one is the usb headset that I have for VOIP stuff. I am going to talk a bit about how alsa/arts can be very frustrating. It bugs me constantly that these devices are being handled really dynamically by default. After every reboot the two usb devices switch places randomly. If I didn't have the integrated i810 but I had for instance Audigy (or whatever external USB sound device - I hear they are actually quite great) I would have 3 always randomly ordered sound devices in my system. I think KDE could help in handling these devices in more intelligent way that is especially more suitable for the Average Joe. Prepare for couple slightly stupid screenshots and then a solution. Let's see how the devices could be handled. [alsa-thinking.png] shows the default stuff. Some of the audio devices gets the first slot (0). For me it is ICH5 because it is probed first (thank god). But if all the devices were handled by usb-audio I would be in trouble with the alsa. Or if I really wanted to use my headset as the default arts device - arts would fail or succeed depending purely on luck. I could order the devices at modprobe.d/alsa-base by giving the drivers option xxxx index=0 and then like index=1,2 vid=0x046d,0x046d pid=08a2,0a02 with the device ids if there were many of the certain type. This could fail however in many cases if some of the devices in the order were not always around. Also furthermore the distributions take slightly different approaches and at least I couldn't figure out how to make it actually work. Take a look at [modules_index.png] .. Now where would Average Joe stuff the settings? Hardly convenient or reasonable. Udev can be used for the stuff as well. Take a brief look at [udev.png]. It's a more powerful solution and more robust. However it requires from the user that he is able to understand how to pinpoint a specific serial numbers or device ids etc and make the alias line. That would work in my case beautifully. Then you would have to however still use the kcontrol to set up some mythical path on the field. Take a look at [kcontrol.png]. You call this user friendly? I wouldn't. In overall all I've got around here sofar has been "can't start artsd", a bit sweat and some tiny insights. I might be unaware of many great ways how to handle these things but I will just show up something that would be a bit handier. It is just imho but the arts/KDE could help here greatly and take a new great role on the desktop, at least in handling alsa. (You might know better though.) Take a look at [kmix.png]! Ooooh.. A dropdown menu. It pretty much tells me in quite clear text what device to handle. That's yummy. Take a look at [kcontrol_new.png]. Now we are talking. How about the Kde having this setting. Or even perhaps a wizard "I will test out all your sound devices. Press the button when the sound comes out from a correct one and I will use it thereon for the audio". But I would settle in for this. Show a list.. "If a this kind of device is ever around, use it. Otherwise if not present, ask these again! (Unless if that feature disabled by user.)" Give a nice name for the device. Come on. We are using alsa. (Well, alsa can do this.. The others.. Well.. It just wouldn't be enabled for the ones not supporting, obviously.) User friendly, even for the newbies and alike. More convenient even for those that have used the Linux for a while. Why there is the separate "input device" then? Why not. I mean, some of us might want to for instance use voip and his microphone and output device are not the same. Like, using the main soundcard's output because it is connected to the speakers and the microphone on the webcam (because it's on a good spot etc anyways.. go figure). Doing this in arts would be great if artsdsp piping could handle it for the dummy applications that are not able to separate themselves. That would be a great bonus for some people. I would think that *something* helping in this area could help the Average Joe in many situations and I would like for the developers to discuss a bit on this matter.
Created attachment 10753 [details] alsa-thinking.png
Created attachment 10754 [details] kcontrol_new.png
Created attachment 10755 [details] kcontrol.png
Created attachment 10756 [details] kmix.png
Created attachment 10757 [details] modules_index.png
Created attachment 10758 [details] udev.png
I forgot to say one more thing. Also setting up what output of a card to use can be quite hard. Take a look at this: furryball@b30:/proc/asound$ cat devices 0: [0- 0]: ctl 20: [0- 4]: digital audio playback 27: [0- 3]: digital audio capture 26: [0- 2]: digital audio capture 25: [0- 1]: digital audio capture 16: [0- 0]: digital audio playback 24: [0- 0]: digital audio capture Notice how the card 0 has two digital audio playbacks. One is actually for the analog and the other is for the digital. Luckily my setup is so that they are both used. Not everyone's are so I fear. So they might be in trouble there. (Where a few hundred lines of compact code and a gui would help them in ~2 seconds.)
aRts is discontinued. Please make sure you have made your thoughts clear to the developers for the next multimedia system we will use, in KDE 4. (We don't know which one it will be, yet)
Question. Will those developers doing the next multimedia system for KDE4 notice this from here or should I do something else too? If yes then what?
No, they won't. One of the highest-ranked engines is gstreamer. Contact their developers and voice your concerns and wishes. ALSA may want to hear a bit as well.
The issue is resolved with Phonon + Solid now (as long as HAL doesn't break compatibility :-( )