Advertisement
Advanced thin client solution for Linux, based on Open Source. Mix Windows and Linux applications on the same desktop. V
| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
An Introduction to Linux Audio (O'Reilly)
An Introduction to Linux Audio (O'Reilly)
Posted Aug 2, 2007 23:02 UTC (Thu) by wertigon (guest, #42963)Parent article: An Introduction to Linux Audio (O'Reilly)
I just find it interesting how complicated all the Linux and/or UNIX sound stuff has become.
As a person who recently gave a shot at this myself, when I asked why everything is in the sorry mess it appears to be, I got directed to a page which is quite an eye-opener.
And you know the saddest part? The thing that sparked this finally got fixed and again released as Open Source. Linux sound has a long way to go yet unfortunately. :(
(Log in to post comments)
An Introduction to Linux Audio (O'Reilly)
Posted Aug 3, 2007 0:31 UTC (Fri) by rfunk (subscriber, #4054) [Link]
I followed your link to the page that opened your eyes, and while its basichistory was decent, after that I found it to be one of the more ill-informed rants
I've read in a while. (Even ignoring the all-too-common confusion of the
words "deprecated" and "depreciated".)
Too bad. I was hoping to have my eyes opened too.
An Introduction to Linux Audio (O'Reilly)
Posted Aug 3, 2007 11:26 UTC (Fri) by ken (subscriber, #625) [Link]
Yes it was a rant and I do not agree with a lot he said the fact is that sound is a mess. I did not know how big a mess until I tried to do some sound work myself about 2 years ago and got seriously confused on what to use. In the end I selected alsa with libasound but it was not based on any evaluation just that since it was supposed to be the new and better way to do it and it was a "realtime" project so I did not want to put more layering than absolutely necessary in the sound path. It's newer that for sure but better ??. That project is in need of someone to make a coherent document on how to use it.
As a user with a soundblaser (emuk10) based one I have a alsamixer covering two three screens width with options most doing nothing at all as far as I know and I never ever know what knob to change.
An Introduction to Linux Audio (O'Reilly)
Posted Aug 3, 2007 14:13 UTC (Fri) by rfunk (subscriber, #4054) [Link]
Seems to me that your issues are addressed in the article. Be sure to read allthe way through to the JACK part. (Despite being an additional layer, JACK is
specifically intended for realtime audio.)
BTW, the emu10k, which I also have, is actually a rather high-capability chip.
Some people like to take advantage of all those capabilities, and ALSA allows
that while OSS doesn't. Don't blame ALSA for the fact that your sound chip has
more capabilities than you need.
An Introduction to Linux Audio (O'Reilly)
Posted Aug 3, 2007 14:15 UTC (Fri) by rfunk (subscriber, #4054) [Link]
Quoting myself:"Don't blame ALSA for the fact that your sound chip has more capabilities than
you need."
... or that alsamixer doesn't have a very good/smart user interface.
An Introduction to Linux Audio (O'Reilly)
Posted Aug 3, 2007 23:52 UTC (Fri) by drag (subscriber, #31333) [Link]
Alsamixer is fine.
It's a low-level way to interact directly with the mixer settings present on your sound card.
The problem is that it's currently the _best_ way to do the mixer settings. There needs to be a higher level way of interacting with it. A standardized something-or-other that effectively abstracts away the differences in audio cards.
A generic way to interact with audio cards can never effectively suit the needs for advanced users, hence the need for alsamixer and the need for something that accurately reflects the capabilities of the hardware.
Our problem is that there isn't anything for people that don't give a crap about the capabilities of their audio card and just want to make recordings.
An Introduction to Linux Audio (O'Reilly)
Posted Aug 4, 2007 8:01 UTC (Sat) by bersl2 (guest, #34928) [Link]
The problem is that it's currently the _best_ way to do the mixer settings. There needs to be a higher level way of interacting with it. A standardized something-or-other that effectively abstracts away the differences in audio cards.HAL, perhaps?
An Introduction to Linux Audio (O'Reilly)
Posted Aug 3, 2007 16:27 UTC (Fri) by johnkarp (subscriber, #39285) [Link]
I don't think you can rightfully blame ALSA for the proliferation of otherAPIs. They generally solve problems that neither ALSA nor OSS can solve
directly. For example:
Portability to Windows & Mac: SDL, Phonon, gstreamer
A/V [de]compression and [de]muxing: gstreamer
Networking: nas
Low-latency interprocess routing: Jack
Interprocess mixing: esd, aRts
An Introduction to Linux Audio (O'Reilly)
Posted Aug 3, 2007 18:44 UTC (Fri) by rfunk (subscriber, #4054) [Link]
ALSA can solve the interprocess mixing problem (with dmix, unfortunately not enabled by default), but esd and arts came about before ALSA was common.I'm still not quite clear on why Jack should be necessary, but since I haven't needed it I'm not in a position to know.
An Introduction to Linux Audio (O'Reilly)
Posted Aug 3, 2007 19:47 UTC (Fri) by drag (subscriber, #31333) [Link]
Actually nowadays dmix is enabled by default. There is no longer any need for a typical end user to muck around with their asoundrc.
The only time Linux, generally, users are forced to deal with Alsa now is when faced by Artsd (which is easy since it can be configured to use alsa) or with OSS-only applications which can't typically use dmix.
Your behind the times by a year or so. :)
Arts is effectively dead. But Pulseaudio has replaced ESD and is API/ABI compatable while being much superior. (esd has always sounded like utter crap..)
If you have need for networked sound I strongly suggest looking at pulseaudio. It supports all sorts of fancy features... For example Zeroconf so that the services will automatically be declared over a network and be picked up by things like Avahi or other pulseaudio software.Also it can be setup to follow X. So if your accessing remote X and there is sound involved then you can use pulseaudio to automatically follow it.
Also there is a 'pulse' plugin for Alsa. This way anything that supports Alsa can be used over the network via pulseaudio.
Jack is very nice for audio work.
It's special feature is that it is low-latency. This makes it suitable for realtime audio editing with multiple audio streams and multiple applications.
This gives Linux a unique advantage with applications that support jack they and route and re-route audio and midi between applications. Software synths, recording applications, midi controllers, LADSPA plugins etc etc. It'll work with internal and external midi stuff and allow you to easily control the I/O on your sound card, both digital and analog for setting up things like monitoring audio channels and playback/record stuff.
You can connect all these things to create very sophisticated super-applications. Sort of like you can string awk, sed, cat, and other things together to make sophisticated text handling applications.
In comparison with typical proprietary Windows or OS X setup your depending on one or another company's flagship product and your options are much more limited.
Combined with special low-latency patches like Ingor Molnar's realtime-preempt this allows a Linux PC to work as a REAL audio workstation and be suitable for studio, dj, and live audio work. Whatever you want. There are currently people selling Linux-based audio workstations for professional/studio-level work.
I think that the difference between desktop audio and network audio is enough that there is enough room for Jack, Alsa, and Pulseaudio to exist besides each other.
Also keep in mind that it's possible to get Jack and Pulseaudio to work together. There are also Jack and Pulse plugins for Alsa applications to use.
For arranging your applications to work through Pulseaudio take a look at:
http://www.pulseaudio.org/wiki/PerfectSetup
An Introduction to Linux Audio (O'Reilly)
Posted Aug 3, 2007 20:01 UTC (Fri) by rfunk (subscriber, #4054) [Link]
Ah, thanks for updating me! :-) Maybe I can delete my .asoundrc then.
But despite its lack of continued development, arts won't be entirely dead until
KDE 3 is dead. Also, my understanding of dmix is that it does work with ALSA's
OSS-compat mode.
I've used arts for networked sound in the past, but now I'll have to look into
pulse.
Last time I looked at Jack (on Debian) it wanted to rip out a bunch of my
sound-related infrastructure, which didn't give me a good feeling. I hope that's
been fixed somehow. (It was probably more of a Debian library issue of the
sort that makes people jump to Gentoo.)
An Introduction to Linux Audio (O'Reilly)
Posted Aug 4, 2007 0:05 UTC (Sat) by drag (subscriber, #31333) [Link]
I don't have any problems with jack nowadays, it should play nicely with everything else.
But keep in mind that it's for audio work. You can't use it with Dmix because dmix adds latency between jack and the sound card. It's not a very convenient or desktop-friendly way of doing things.
> But despite its lack of continued development, arts won't be entirely dead until KDE 3 is dead.
Yep. It's pretty much impossible for a normal user to use any KDE application and NOT use Artsd. The KDELibs will start artsd up automaticly when you launch applications. But it's not a difficult problem to deal with since artsd can be set to use Alsa and that solves most of the problems people have with it.
> Also, my understanding of dmix is that it does work with ALSA's
OSS-compat mode.
Sorta.
With Quake3-style games, for example, requires support of 'mmap' in the audio card for this to work. Some cards simply WILL NOT work with these games and OSS and although alsa supports mmap emulation I can't seem to get it to work.
(although with artsdsp -m they will work.. so you can go artsdsp --> artsd ---> dmix ---> alsa, though with the penalty of pretty high latency)
Also normal oss applications with dmix/alsa you need to start up applications with the the aoss wrapper. Using this they can work with dmix and play well with everybody else.
An Introduction to Linux Audio (O'Reilly)
Posted Aug 3, 2007 19:55 UTC (Fri) by johnkarp (subscriber, #39285) [Link]
Say you are using a computer to do audio recording in a studio. With Jack,you could route inputs from various audio interfaces into various effects
plugins, send some to a multitrack recorder, and also combine them all
into a mix for the musicians, so they can play off the effects. During the
recording session, you can easily reroute the signals from a central
patchbay.
You could probably hack together a workalike with other Linux audio
technologies, but it would be unusable because of the latencies. (Its
difficult to play an instrument well when you can only hear what you were
playing 0.3 seconds ago.)
I don't think Jack will become the standard general-purpose audio API
though, because each user on a system requires a separate Jack daemon that
has to run with realtime priviledges.
An Introduction to Linux Audio (O'Reilly)
Posted Aug 3, 2007 20:14 UTC (Fri) by rfunk (subscriber, #4054) [Link]
My Jack confusion is/was mostly about why ALSA couldn't do it all internally.But I think the part about multiple audio interfaces is what I was missing.
An Introduction to Linux Audio (O'Reilly)
Posted Aug 17, 2007 21:07 UTC (Fri) by ehowland (guest, #46882) [Link]
I read those articles and am quite interested that OSS is now GPL (or CDDL depending on your operating system) as noted here before
The key questions is whether anyone will care and if the trend toward ALSA will slow or stop.
Hannu's blog ( http://www.4front-tech.com/hannublog/) suggests that the version of OSS that is now in the kernal is not very good and in the 10 years since they closed it have really improved both the API and the quality of the code. Will OSS come back with the new API or continue to fade? I cannot comment on developer's preferences as I have not done any sound development, but if this means that OSS is no longer depreciated then I guess developers will vote with their code.