Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
|
| |||||||||||
Linux desktop architects map out plans for 2007 (Linux.com)Linux desktop architects map out plans for 2007 (Linux.com)Posted Dec 17, 2006 12:38 UTC (Sun) by drag (subscriber, #31333)Parent article: Linux desktop architects map out plans for 2007 (Linux.com)
Most of things that people dislike about Alsa have been solved a while ago.
for instance nowadays all sound cards support mixing by defualt. Either through hardware or by dmix. By default.
Sound cards are all configured automaticly by start up scripts.
Most people run into problems because you have things that like to use Artsd, or esound, or OSS.
Those things obviously don't benifit from anything from Alsa. So obviously Alsa is not going to make these things easy to deal with.
Not only are they difficult to deal with, but they interfer with proper operation of your sound system.
You can have as many instances of mplayer you want, totem, or anything else running.. but as soon as you start something that has been configured to use OSS then it's going to all turn to shit.
So a distro needs to configure libao to use alsa. They need to replace applications that do OSS-only with ones that can use Alsa. They need to replace esound with pulseaudio. They need to configure artsd to use alsa by default. etc etc.
(Log in to post comments)
Linux desktop architects map out plans for 2007 (Linux.com) Posted Dec 18, 2006 18:24 UTC (Mon) by bronson (subscriber, #4806) [Link] I don't know... The single largest problem that has plagued Alsa since day one -- usability -- is still a crippling problem.
Want about 20 minutes of entertainment? Ask your whiz-kid Mac-using little brother over to your computer and ask him to enable S/PDIF output. He'll hunts through multple GUI mixers looking in vain for something that says 'spdif'. You can laugh at his confuson when he realizes that the Gnome Sound control panel doesn't actually allow him to modify his sound settings.
Now, this kid is _smart_. You can watch in amazement as he figures out how to invoke lspci and finds out the PCI IDs of the card. He looks up the manufacturer and does some Googling. He finds instructions that require calling amixer. Not a problem, he knows how ot use command line. Too bad the instructions are from 4 years ago and silently fail to work anymore. It's about here, after 1/2 hour of thrashing, that any sane person will give up.
You can do this for any non-trivial sound setting. Enable 5:1 output? AC-3? 3D stereo? Endless hours of entertainment.
Alsa is flat out unusable. It's an embarrasment. On Mac and Windows, these settings are single check boxes inside an easy-to-find control panel. On Linux, unless you're looking to spend an hour learning the ins and outs of alsactl and editing obscure text files, these simple tasks are simply impossible.
So, yes, Alsa works as long as all you want to do is set output and mic levels. For anything else it still has a long, long way to go.
Linux desktop architects map out plans for 2007 (Linux.com) Posted Dec 19, 2006 3:14 UTC (Tue) by zlynx (subscriber, #2285) [Link] You're blaming the wrong thing here. What you want should be the job of Gnome or KDE. Would it make anyone feel better to rename the ALSA mixer to rawcardctl or something? Probably not.
Besides, the name works. Look at a real mixer board sometime. Sure, volume sliders make sense, the toggles for input/output mute make sense. But what does that knob with the bit of sticky tape next to it marked "SpecDir A2" do and what does that bit of tape mean? It's just as meaningless as the ALSA mixer, and without reading "Special Directions section A2" you'd have no more idea of what that real-life mixer control did than ALSA control "IEC958 Playback AC97-SPSA".
Linux desktop architects map out plans for 2007 (Linux.com) Posted Dec 19, 2006 14:46 UTC (Tue) by otaylor (subscriber, #4190) [Link] This post encapsulates exactly what is wrong with Linux audio: it has largely been developed by and for people's who's model for how sound should work is a mixing board with bits of tape stuck on it. :-)
Linux desktop architects map out plans for 2007 (Linux.com) Posted Dec 19, 2006 7:02 UTC (Tue) by drag (subscriber, #31333) [Link] 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.
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.
Linux desktop architects map out plans for 2007 (Linux.com) Posted Dec 22, 2006 16:29 UTC (Fri) by JohnNilsson (subscriber, #41242) [Link] An other step could be to formalize the hardware description. Something along the lines of how XKB defines keyboard geometry.
This way GUIs could at least provide something more sensible than alsamixer when you need to mess with the details of the hardware.
|
|||||||||||