Linux desktop architects map out plans for 2007 (Linux.com) [LWN.net]

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

Posted Dec 18, 2006 15:55 UTC (Mon) by drag (subscriber, #31333)
In reply to: Linux desktop architects map out plans for 2007 (Linux.com) by tialaramex
Parent article: Linux desktop architects map out plans for 2007 (Linux.com)

The trouble is that each audio card is going to be different.

So that the mixer controls and settings for one card in alsamixer isn't going to work for other sounds cards.

For example take these three cards that have good support in Linux:
emu10k1 driver for my first gen Creative Audigy.
ice1712 driver for my M-Audio Audiophile 2496.
intel8x0 driver for my old nforce2 board.

All three of these use vastly different ways to set recording over mic or line-in.

With the intel8x0 it's fairly standardized since it's a generic driver. You hit 'space' on the item you want to record from then you fiddle around with the mixers till it sounds good.

Now that won't work for either the ice1723 or emu10k1 driver. With the emu10k1 there is a selection you have to go into to choose the device to pick from then the mixers are different from the intel8x0.

With the ice1723 I am not even capable of using alsamixer with it. It's totally different having a different set of I/O then a normal sound card. (it's more a 'pro-sumer' class card). It has it's own paticular mixer application you have to use to set the settings for it.

So then there is more things you have to deal with.

For instance setting SPDIF out on these guys are all very different. Setting up surround sound are going to be different.

So although alsa does a good job exposing functionality to users in a way that OSS could never do (without a crapload of hacks).. and the plugin architecture is very nice it still is difficult for end users to deal with because they have to have good knowledge of the paticular sound card since it's very different for each sound card.

What is needed is a way to expose functionality to users in a abstracted way so that it's standardized. That way then you can write documentation and GUI applications in such a way that it makes sense to naive users.

Now this has to be oriented for _desktop_ users.

For audio workstation then that's going to be different set of problems.

(Log in to post comments)

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

Posted Dec 19, 2006 9:27 UTC (Tue) by nim-nim (subscriber, #34454) [Link]

IMHO you're still thinking as an app writer.

App writers don't want to mess with card differences so they're asking to simulate a stupid card in all cases (the KDE thing is in a step in this direction), and pretend we still use the OSS soundblasters of last century.

Users OTOH do want to take advantage of the card they shelled out precious money for. If it has twenty output/outputs they *want* access to the twenty outputs (and apps just have to live with it).

Now access does not mean a long list of raw controls labelled in english sound engineer tech-speak (i18n audience remember) with no explanation how they relate with each other (Alsa insisted in calling the main volume knob on one of my past cards "DAC volume", it may be right technically but what's bloody use is it for a user).

Access means users can easily test each I/O plug and label it with the name of the device plugged there, and have this device name appear in apps (to take a bad analogy : you don't expect users to select network printers by IP in office apps, but that's exactly how the alsa UI works). Access means giving users a pretty graphical representation of their chip pipeline, so they know foo control works on bar output and are not required to test them one after the other till they stumble on the one that works. Access means renaming controls depending on the input/output chosen, instead of requiring users to remember that in a particular mode a particular slider must be used. Access means selecting a default volume baseline for each input/output, to take into account all devices have not the same loundness level. Access means automatically choosing the best chip mode depending on the output device & input stream.

Most of this BTW does not need to happen in apps, video/sound apps only need to expose the user-labeled I/O list, not reconfigure all the card every time (that ekiga needs to perform some of these steps itself for example is an indictement of the sound system infrastructure state)

And it's not rocket science, any set-top DVD reader with more than one output has been doing it for years (and they used to say VCRs are a UI nightmare).

Also I don't get the "every chip is a particular case" argument. Other hardware subsystems somehow manage to handle their particular range of diversity way better. Instead of (at best) cloning every particular proprietary windows control app without thinking about commonalities, alsa writers would be well advised to take the best parts of each of them and create a generic user-friendly control app. That would make basic users happy. Make users happy and app writers will follow suit.

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

Posted Dec 19, 2006 14:57 UTC (Tue) by pizza (subscriber, #46) [Link]

>Also I don't get the "every chip is a particular case" argument. Other hardware subsystems somehow manage to handle their particular range of diversity way better. Instead of (at best) cloning every particular proprietary windows control app without thinking about commonalities, alsa writers would be well advised to take the best parts of each of them and create a generic user-friendly control app. That would make basic users happy. Make users happy and app writers will follow suit.

Do you know how many different (and subtly-incompatible) AC97 codecs there are? There is no "standard AC97 device" but rather a bazillion different codecs that differ enough as to make the "standard" almost meaningless. (And it's said codecs that provide the actual mixer interface!)

Every model of audio board (including different motherboards with the same audio chipset) uses a different proprietary windows driver, mapping the hardware-specific stuff to the generic windows mixer, and occasionally providing a proprietary mixer to drive chip-specific stuff in a completely non-standard manner.

Because of this "standard mapping via a proprietary driver" windows just works for basic audio in/out. But ALSA doesn't have the benefit of every motherboard maker and every board maker creating that shim layer; ALSA has to "just work" and automagically detect everything, soft-ports and all. It does a remarkably good job given the nightmarish task expected of it.

>Access means users can easily test each I/O plug and label it with the name of the device plugged there, and have this device name appear in apps

This is an excellent idea, and I believe it's been possible for some time now. All we need is some enterprising individual to devote considerable hair-loss to writing an app to do all of this, and maintaining a database of every card and motherboard under the sun.

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

Posted Dec 19, 2006 15:43 UTC (Tue) by nim-nim (subscriber, #34454) [Link]

To give some perspective, I believe the variability of printing devices (from el cheapo inkjets to departement colour printers with special papers types, input trays, stappling, resolution, job format, network protocol...) for example is at least as big as the one of sound chipsets.

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

Posted Dec 19, 2006 18:42 UTC (Tue) by pizza (subscriber, #46) [Link]

It's nowhere comparable, because as far as the app is concerned, it just spits out a batch of generic postscript that gets automagically translated/redirected/etc to the printer by the backend. It also doesn't happen in realtime and doesn't allow multiple users to access it simultaneously. (hence the term "print job")

All an app really needs to print is the paper type (to get the size, margins, etc.) Everything else is just an opaque knob that's passed down to the backend unchanged, embedded in the postscript file.

Additionally, the printer configuration/dialog boxes are also not provided by the app, or even the system printing backend, but rather the desktop environment/libraries which is aware of several backends yet hides all of this from the end-user.

So if you're going to compare this to ALSA, you need to harass GTK/Gnome or Qt/KDE to provide a single thunk/configuration layer when it comes to sound. And I believe that's exactly what TFA claims is the point -- right now there are several capable layers, but they don't coexist.

Meanwhile, if you really want compare ALSA with printing, you'll need dialog boxes to allow you to automatically reroute two automatic document scanners to four different printers, while translating your 3-D imaging system to a CNC milling machine (and a hologram printer, oh, and also on the other four printers). Naturally every bit of equipment is a different brand/model, but we should being completely aware of the capabilities, resolution, speed, cost, and various knobs of each and be able to visualize every possible combination. Oh, and doing it all in hard realtime, changing/scaling/morphing the output based on sliders you're moving on your desktop while combining this with the output of five different applications that want to use two of your four printers, one of your scanners, and that CNC machine, all at the same time.

Or do you "just want to print?" *chuckles*

Linux printing used to be "a mess", but it wsn't the low-level stuff that sucked -- it was the higher-level (desktop-level) interfacing with the low-end stuff that was terrible. It took a lot of hard work to build that high-level stuff, including modifying the low-level stuff to more easily expose its knobs in a generic manner.

Sound is much the same way now, except Linux's low-level stuff (ALSA) is perhaps the most capable API out there, doing nearly everything for nearly everyone -- but because every soundcard is different, we have no idea what "sane defaults" are for many situations/tasks, and that's the crux of this mess. Mapping these raw hardware controls to a "desktop task/profile" is the job of the desktop environment.

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

Posted Dec 19, 2006 19:22 UTC (Tue) by nim-nim (subscriber, #34454) [Link]

Don't take it bad, but if ISVs complain about Alsa that's because they're not getting frantic requests from their users to support it, and if users don't care that's largely because Alsa never made their life better/easier.

Alsa people have this strange notion Alsa will sell itself to app writers and users, despite offering little or no benefits so far, and lots of pains (API complexity, config complexity). Or alternatively someone else will make everyone grok Alsa goodness.

The problem is neither GTK/Gnome, nor Qt/KDE, nor ISVs have any reason to promote Alsa in its stead. (I won't even talk about other sound projects graciously giving up so there's only the Alsa API left to choose). When ESP pushed cups to replace lpr/lpr-ng it proposed a great end-user front-end to prove its solution goodness. Fluendo is writing Elisa to sell gstreamer. What did the Alsa project ever do to demo its baby?

Like everyone else, I like the bright sound future Alsa paints. And then I get home late after work, have to fight the damn Alsa controls to do the simplest things, and suddenly Alsa is not my darling anymore.

(I won't write about the print analogy anymore, because obviously you have little knowledge about that part, and I'm not here to flame)