Linux desktop architects map out plans for 2007 (Linux.com)

Linux desktop architects map out plans for 2007 (Linux.com)

Posted Dec 19, 2006 7:02 UTC (Tue) by drag (guest, #31333)
In reply to: Linux desktop architects map out plans for 2007 (Linux.com) by bronson
Parent article: Linux desktop architects map out plans for 2007 (Linux.com)

Well aside from the fact you have alsamixergui and gnome-alsamixer which is a fairly intellegent front for doing mixing, I understand were you coming from.

The problem is this how it goes...

When you control using Amix or alsamixer these are the actual interfaces provided by the hardware itself. The names are pulled from the hardwar itself, I beleive.

If your 'ctl.!default' is hw:0 it realy should show the hardware mixing devices. I think this behavor is very correct. If a user wants to control the hardware directly then they should be able to.

But alsa does not nessicarially have to expose hardware directly to userspace. The way it's currently designed you can setup a asound.conf and asoundrc and then setup your own interfaces through the configuration of various plugins.

For instance the most common one is dmix, which is a software mixing plugin for allowing many applications to play sound at once. So instead of going directly to the hardware the sound application goes directly to the dmix, which then sets up a audio format and does the mixing then sends that to the hardware.

Well it not only works for sound output, but you can do that for mixer controls also. You can intercept mixer controls and present a abstracted image to alsa applications. For example when I am using 'pulse' plugin all the hardware mixing interfaces are removed and replaced with a single volume control when I open up alsamixer.

Now the reason why it's so difficult to get spdif working is that each and every sound card has a different way of doing it. ac'97 sound cards, intel-hd sound cards, emu10k1 sound cards, ice1724 sound cards, etc etc. all have different hardware interfaces.

So we need to figure out a way to use alsa and it's plugins, to setup a idealized mixer interface to user space.

One possible way is to have data files provided with every driver. These files would provide details in a xml format or something that can be automaticly used to generate a asound.conf file to provide several main tasks.

For instance you could possibly set it up so that for desktop integration your require '5 tasks' that must be profiled for each sound card.

Using these tasks then a idealized mixer interface is exposed via the Alsa API.
A. Master volume control.
B. Mixer volume control.
C. Sound input selection. (line-in, mic, mic-boost, or spdif-in)
D. Sound output selection. (stereo out, surround out, or spdif out)
E. Special features. (such as 3d effect)

I don't know, but I am guessing that that would be sufficient mixer interface for 90% of the users. If the sound card or driver does not support that feature then it shouldn't be present.

Then with the '5 tasks' choosen users with aviable hardware can create a configuration for each the tasks and send them to alsa which may be included with a alsa-data tarball or something. This way developers if they make a change to a sound card they can edit this file and it wouldn't disrupt user-land. People having problems can then work with distros to provide a superior task to replace the one they have trouble with.

Then for 10% of the users were this is not good enough they can then set their defualts to 'hw:0' and do it like we do now.

---

to post comments