Submitted by Lennart Poettering, main programmer of the PulseAudio project, has written a ‘Guide Through The Linux Sound API Jungle‘: “At the Audio MC at the Linux Plumbers Conference one thing became very clear: it is very difficult for programmers to figure out which audio API to use for which purpose and which API not to use when doing audio programming on Linux. So here’s my try to guide you through this jungle.”
from the article:
“OSS should be considered obsolete and not be used in new applications”
This is total bulshit, we have OSS4 which is totally free and open source, it is avialable at any license you can think of (BSD/CDDL/GPL), it is cross platform, works on any popular UNIX and yes, also Linux. Has great and complete documentation along with great and STABLE API, Allows per aplication volume, with live mixinig of sound and may more.
Its SUPERIOR to ALSA shit, which has all these userspace layers because ALSA is not there for the job.
This article is a FUD actually :/
You want API Jungle? Just enter Linux ALSA world:
http://blogs.adobe.com/penguin.swf/2007/05/welcome_to_the_jungle.ht…
OSS4 is the best way to be sure that your app will be running good and be trully cross platform if it goes for sound.
Edited 2008-09-27 22:46 UTC
You need Sanka brand.
And comments like this are exactly why audio will remain to be a jungle for the foreseeable future.
Edited 2008-09-27 23:09 UTC
Totally agree. The Linux sound scape should be unified. Its really OSS’s fault if you think about. They had a perfectly good sound api that Linux community was happy to use, but their licensing sucked, they didn’t update it regularly enough and it was lacking features needed. So OSS4 comes out and Linux is supposed to drop ALSA because now OSS gets their head in the game?
I think what Linux needs is total redesign of the sound subsystem, or at least some sort of consolidation, to make it easier on developers. CoreAudio is a great, its easy to use, it robust and it can be used in in professional audio projects as well, as less demanding applications. Right now we have way too many api’s that are confusing.
their licensing sucked, they didn’t update it regularly enough and it was lacking features needed.
…so it seems that there were good reasons why Alsa was created.
Alsa is the future of the Linux sound, get over it.
Interesting. It’s not that I know a whole lot about it, but from what I’ve been reading on the net it seems that the Linux developers went totally overboard when they dumped OSS entirely and started a complete rewrite of the sound system.
What was the problem that prevented forking the last free OSS version and continue development in parallel? Why was it necessary to create a Linux-only sound solution? Was it really necessary to deliberately fragment the Unix systems even more?
As noted before, I’m no expert in this, so any insightful comments about it are appreciated.
Old OSS was a very rudimentary API that’s however still in wide usage. So it was a better decision to start from scratch. Anyway, it wouldn’t make a difference with current (Pulseaudio) problems even if they forked off OSSv3 (i.e. no kernel mixer allowed in Linux). So it really doesn’t matter if they started from scratch or extended OSS interfaces (even better, they support OSSv3 via ALSA kernel emulation, though not with dmix or PA).
Since ALSA was started by Linux hackers, they went Linux only, which makes development much simpler (see DRI/DRM and how much problems they had with merging their shared Linux and BSD code upstream). It’s not uncommon, many of driver frameworks are OS specific. Also, I believe noone from other Unices was seriously interested (no wonder, these are mostly server systems where OSS is often enough for their users).
And about other Unices – they are free to implement whatever they want in their kernel, but not justified to criticize Linux devs for choosing API they see fit. It’s just not their business if Linus decides to smash in some code or not. There is no standard that mandates same API either.
It doesn’t matter!
Trust is slowly build and easily lost, users were burnt by OSS licensing issues, why would they ever trust again OSS?
They won’t, remember ReiserFS 4?
It wasn’t included in the kernel for many reason, but one of the main reason was that kernel developers didn’t trust Reiser as he didn’t maintained properly the previous FS.
quote from FAQ:
“You idiot, you have no clue!
You are right, I totally don’t. But that doesn’t hinder me from recommending things. Ha!”
this article is pretty nice for developers just getting into linux audio. especially considering the author’s affiliation with pulseaudio. i’m glad he’s being forthright about pulseaudio’s purpose and not trying to make it out to be some magical one-size-fits-all solution, like some people not related to the project seem to believe.
but, from an end-user perspective, most of the confusion is very much blown out of proportion.
if you’re a typical linux user, you ARE using ALSA, unless you’ve gone out of your way to avoid it. ALSA simply provides audio drivers for your soundcard.
if you’re using a desktop environment, you probably are running an additional sound daemon so that multiple applications can output audio simulaneously, like a software mixer. if you’re on an older gnome distro, this is ESD. on a new gnome distro, it’s probably pulseaudio. if you’re on an old KDE distro, this is arts. on a KDE4 distro, phonon, i guess.
none of these things are choices a typical user has to make. they’re all just small pieces of the pie.
the only time an end-user really should have to make a choice is if they are doing any professional audio work. if they need a low-latency solution with inter-application audio streaming, then it’s advisable they read up on JACK.
honestly, that’s really all there is to know for MOST end-users.
your hardware talks to ALSA, which talks to your sound server, and add JACK if you need to use professional audio software.
the only truly damning problem is when a distro ships a misconfigured sound setup and the end-user is forced to troubleshoot with no background knowledge. for example, the latest ubuntu release with it’s funky pulseaudio setup.
lastly, the OSS situation really depresses me. is it superior to ALSA? maybe it is, maybe it isn’t. but, ultimately, they shot themselves in the foot with slow updates and licensing problems. ALSA superceded them because we NEEDED a solution we could count on. they didn’t catch up until it was too late. crying that it’s not fair isn’t going to change the fact that OSS missed their window of opportunity. heck, they *squandered* their lead.
Actually, as soon as commercial apps enter the mix the end user usually does have to deal with it, unless they have one of the few hardware multi-channel cards that ALSA actually supports. Most commercial apps use OSS and believe me, ALSA+OSS+PulseAudio is not a trivial setup to get working, seeing as how ALSA’s oss layer is basically worthless–nothing sent through it uses any of ALSA’s settings, so it pretty much ignores your pulseaudio setup. Sure, you can use padsp or preload whichever DSP library you need, but that doesn’t work in all cases–try that in vmWare workstation and see how far you get, for instance. Try it with audacity, you won’t get very far. Perhaps OSS did shoot themselves in the foot in regard to their licensing and slow updates–I’d say that’s a given. But why did ALSA have to completely redesign the API? For the longest time, ALSA wasn’t stable–remember the days of ALSA 0.4 vs 0.5 vs 0.9? Why are the drivers in many cases immature? Why is there no reliable way to switch the default audio device, something so simple? Why is ALSA’s software mixing layer so bad that we needed Pulseaudio in the first place? Why is the OSS emulation layer half-baked even after all this time?
The OSS API is stable, standard, and simple. I agree that the Linux audio system needs to be rebuilt from the ground up. If the kernel DEVs don’t want to use OSS, at least implement the API properly. It would increase compatibility and decrease frustration all around. Oh, wait, that would take foresight and organization. I guess I was just dreaming.
Oops didn’t mean to accidentally imply that Audacity was a commercial app.
actually, i don’t find it difficult to get a decent working setup with ALSA + JACK. i don’t use many OSS-only apps at all. and frankly, there are very few commercial apps written for OSS, in the grand scheme of things. if you’re going the commercial-software route, linux is (sadly) not the best platform for audio work.
there are many multi-channel cards with support. admittedly, there are still many very popular interfaces with no support in ALSA. FFADO picks up some of the slack for firewire interfaces. but, the lack of proper drivers (ALSA, OSS, and FFADO) is the fault of the hardware developers for refusing to provide specs. and it’s not like OSS has oodles of support from manufacturers that ALSA is lacking.
ultimately, it’s pretty simple nowadays to get a decent setup going for multi-track recording. RME and m-audio pci interfaces have decent ALSA drivers, and echo makes some great FW (and PCI) interfaces. add a mixing console, jack and ardour, and you’ve got a quick and easy recording studio.
it’s not that we have a perfect situation… but, if you have a workflow that necessitates commercial software and unsupported hardware, linux just isn’t what you should be using right now.
all of this is sort of a silly discussion though. in my original post, i was just trying to point out that for most typical (i.e. non-pro) users, the confusion is really artificial and not at all necessary. for mr. average joe with onboard audio, everything usually just works.
edit: forgot to mention pulseaudio. for any of my studio boxes, pulseaudio is not even installed, or necessary. it’s really just ALSA + JACK for me.
Edited 2008-09-28 01:12 UTC
My point wasn’t how to set up a recording studio, my point was merely that the end user often does have to deal with it more often than one might think. I agree, Linux is not the platform for commercial software, and if the situation stays like this it never will be. For my intensive audio tasks, I use a Mac.
๐ when i read “multi-channel” my mind went straight to “for recording”… it didn’t even dawn on me that you might be referring to consumer multi-channel, such as surround-sound.
i have very little experience with consumer-grade multi-channel cards. BUT, on the pro side, there are many massively multi-channel sound cards with excellent support.
i used to use a mac for my recording. but, i’ve actually really gotten hooked on the workflow that linux + jack + ardour enables. of course, there are excellent mac ports of jack and ardour, as well. their usage just seems so much more cohesive on linux.
To each their own, but I just find the ridiculous amount of audio APIs on Linux to be more frustration than its worth. Just to clear up what I meant by multi-channel, I was referring to surround sound, and also the ability of a sound card to output multiple sounds at once at the hardware level, such as the emu10k1-based cards do. The majority of Linux drivers don’t seem to implement this even on cards that support it, preferring to rely on software-based solutions. The emu10k1 and some M-audio cards are among the few on which Linux will actually support true multi-channel. I say get the drivers cleaned up before stacking user process ontop of user process like we do now to make up for the lack of some high-level features. Some people don’t think there’s an issue with the Linux audio stack, and they’ll continue to think it until it turns around and bites them and they have to work out how to get around some of the issues.
there are many, many, many issues with the linux audio stack. my point is only that, once it’s explained, it’s not as complicated and confusing as it’s often made out to be. most end users really don’t have any trouble at all. they are happy that sound is coming out of both craptastic speakers that came with their cheap dell. the recent ubuntu 8.04 pulseaudio configuration debacle was the only time in recent memory that major audio problems have hit mr. average joe.
that being said, there is SOOO much room for improvement. but, the benefits offered by OSS are apparently not enough to make up for their lost ground.
the biggest issue is really hardware support. and all we can do is continue to petition hardware makers to either write drivers, or give us specifications so that we can write our own.
yes, it sucks that ALSA’s OSS support is so crappy. but, ultimately, OSS’s time has passed, no matter how much moaning (very few) people do. most linux audio developers have moved on a long time ago. most aren’t even developing directly for ALSA. they’re targeting one of the abstraction APIs, or JACK for pro stuff.
If we had a stable ABI and API in the kernel we wouldn’t have to rely on reverse engineering or petitioning manufacturers to release the specs. They might actually be willing to write drivers for Linux. But I digress.
OSS’s time may have passed on _linux_. But the thing is, just about every other UNIX platform out there uses the OSS API, even though they might not use the OSS drivers. The only other UNIX that doesn’t use the OSS API is Solaris (they use SADA) and even they emulate the OSS API very well. The issue with the abstraction layers is that there are so many, not that it’s a complicated ecosystem of sound drivers and APIs. Gstreamer, Pulseaudio, Phonon, ARTS and ESD (yes you still occasionally see those, though hopefully no one in their right mind uses them now). If they’re going to pick one though I’d have to agree that Jack would be the better option. If set up properly, and a GUI configuration tool was properly written, it would be fairly easy to set up jack as the default and make both the average joes and the users happy. If media software insists on using Pulseaudio guess what, Pulse can connect to Jack very easily. One way or another though I think that, except for the abstraction layers, the ALSA API needs to go. OSS support does need to be improved for cross-platform purposes unless we want the situation to become more complicated in the future. OSS’s biggest advantage (the API, not the drivers) is that if you write something using it, it will run on Linux, *BSD, and Solaris to name the big three families of UNIX in the PC world. Most of the other platforms don’t seem interested in adopting anything else as a standard, though Pulseaudio does run on FreeBSD and Solaris. However, being able to use it doesn’t mean they will or wish to adopt it. . It’s either convince them or give a bit of ground in the Linux world.
“Just about every other Unix platform” sounds impressive at first. But how many people care about audio at all on OpenBSD? How many do audio recording and mixing work on NetBSD? AIX? Irix? So the only one worth talking about here, if it is worth talking about here, is FreeBSD. “Just about every other Unix platform uses” effectively means “FreeBSD uses”.
Edited 2008-09-28 12:53 UTC
sorry, but how many people care about audio on linux? all my servers run fine without sound card (i even prefer it that way). all thin client desktops can do without sound (you don’t need sound in your office suite).
the only real reason to have sound is to play some music. wanting to do more than that is complete madness. it’s likely you can’t find any software, your vst’s won’t work and maybe more. games almost never work natively so advanced 3d sound is also not required. when doing remote work i can use ssh and do xwindows stuff. i have absolutely no clue how to get audio working remotely. and even if i know how it most likely won’t work with windows and osx. linux and sound simply don’t mix (no phun intended).
if linux wants to be taken seriously for audio it should supply it’s developers with one working api for all sound and supply it’s users with one program which tweaks the audiocard.
just take a look at beos. even after being death for so many years it still has better audio tools than linux has today. maybe it was because the developers could target one stable api.
to uz64:
supporting multiple audio systems is not possible since they need exclusive access to the audio hardware. this has bitten me when i tried to develop using /dev/dsp directly. in that case no other audio could be played. and this resulted in crashing other applications. maybe they fixed it nowaydays but it caused me too much trouble.
um… nearly every single person trying to use linux as a desktop operating system cares about audio on linux.
try to tell that to the huge community of people using linux to power their recording studios, myself included. it’s not madness by a long shot. there is a certain amount of knowledge required to understand pro-audio concepts on any platform. it’s easy to jump the gun and say that something is overly difficult or convoluted when you have no understanding of the concepts at hand. i’m not trying to pick on you; but, putting together a professional audio environment on ANY platform requires work.
…this is *exactly* what I don’t like about Linux. There’s just too much damn confusion and not enough clarity on some things. Competition is good, yes, but too many options muddies the water and is incredibly counter-productive.
I truly believe that now is the time for the developers to sort out this Audio API mess and get going with only a few modern, forward-looking API’s like GStreamer and PulseAudio for the mainstream users and abandon the rest (except very specific and specialized ones like JACK, which music producers really need).
Xactly. Just reading this stuff makes my head hurt. It’s 2008 for crying out loud… they need to get this shit handled. Just ONE sound framework that works across the entire OS and kick ass.
Aasron Seigo’s reply:
http://aseigo.blogspot.com/2008/09/linux-audio-layers.html
ASiego needs to get over himself. I did’t get any kind of semblance of FUD from Lennarts article. What I got from it was that Phonon and KNotify were QT specific and thus not very useful for anyone else not using QT for their applications. So while the author Lennart should have said KDE/QT, its still a valid point, imo.
agreed. he packs every sentence with vitriol and self-righteousness, and it really comes across as anti-user. even when he’s right.
the truth is, loading required QT libs to run phonon is kind of pointless extra overhead if you’re not running KDE. that’s really the bottom line.
Also agreed. Though it was quite expected; That’s typical asiego and I was wondering how long it would take.
From what I can see, Lennart wrote “KDE” once when he should have written qt, and that’s about it.
Edited 2008-09-28 21:24 UTC
Did he really? I suppose when you see rather silly and absolute statements like these that imply something else altogether, and you are a developer who knows a bit more about this stuff, then I suppose you’re entitled to comment:
You can equally apply these statements to libcanberra or half a dozen other things. He also fills the thing with crap about libcanberra being synonymous with the XDG sound and theming specifications – look, this is a standard and that KNotify thingy doesn’t follow it! Gnome has only just got support for this stuff in the most recent version. Lennart then tries to spin this round in the comments by saying “But if there’s not much coming from your side that’s your problem. Deal with it.” Uh, huh. Cheers.
There is also not one single mention of Xine, which I found quite bizarre. It has proven itself to be more stable and reliable for many than GStreamer has for the past umpteen years, and in all honesty, is probably much more popular for the vast majority who are looking for something to work. Unfortunately, GStreamer just hasn’t become what some people, including Lennart, have hoped after several years, and KDE and Qt have sensibly decided not to tie themselves to it. He seems not to understand that Phonon can use GStreamer.
GStreamer is fast becoming yet another road accident amongst many in the Linux multimedia landscape, and don’t be suprised if a few people can see that coming. Bugger, we’ve even got PulseAudio now to add to the mix. Deal with it Lennart.
Edited 2008-09-28 23:23 UTC
Segedunum,
You obviously did not read any of Lennart’s followups in the site comments. He does indeed deal with most of your objections there. If you are going to rant, please at least read what has already been covered on the story page to avoid needless rehashing and redundancy.
Edited 2008-09-29 00:55 UTC
You obviously haven’t read the part where I quoted what he’d actually written in the comments. That’s where the ‘Deal with it’ stuff comes from. I quote:
I don’t find that terribly helpful to be honest.
We also get gems like this:
He still doesn’ get what Phonon is, even after all the reading he has done and posting to KDE lists which he has allegedly done. Errrr, because Phonon is an abstraction layer for desktop developers, and you need an implementation underneath such as GStreamer or Xine, so it is perfectly legitimate to compare GStreamer with Xine, or MPlayer as well, because these make up the bulk of the software that people actually use to watch DVDs, listen to music and do other multimedia type things today. He never touched on more professional audio type applications either, which is the one thing you probably can’t use Phonon to interface to underlying software for.
I would advise you to do the same sweetheart, because you obviously haven’t read either what I wrote or the comments in the article or the article itself. Bugger, you didn’t even know how many times he’d actually wrote KDE in there, or in what context. Calling it a rant is an easy way out I suppose, but it doesn’t make the article any less useless in terms of what the Linux sound landscape actually looks like for many people. Linux multimedia != GStreamer.
My impression is that you scanned until you saw the words “deal with it”, went ballistic, and started ranting here. Now that you have actually read at lest some of the supplementary comments, I would like to call your attention to this one which you did not quote:
This is why phonon is only really useful for C++ apps (and maybe Python), and not generally useful outside of that. (And yes, I know what Phonon is.) That was a basic design decision made long ago by Trolltech and the KDE team which, despite any benefits it might have, also has some present day consequences which, apparently, you would like to sweep under the rug and ignore. However, the author of a guide for developers has a responsibility to mention practical limitations. And attacking him for doing so only suggests oversensitivity on the part of the attacker or attackers.
“Deal with it” is probably not the most appropriate ending for this post. How about “You’ve made your bed. Now lie in it.”?
Edited 2008-09-29 12:34 UTC
Your impression is wrong I’m afraid, and it was deliberately wrong for reasons that are best known to you.
Cheers, but I already had, as you well know. Lennart even equated Phonon to the functionality of Xine which is why he says he never mentioned Xine, which is not what Phonon is, as I’d pointed out.
Yes I know, and that tac is what Aaron was explaining as wrong. For some reason, Lennart, and others like Christian Schaller, have went overboard with Phonon because they think KDE developers are trying to get everything, including non-Qt and KDE apps, to use it. That’s a strawman I’m afraid, because that is not what was argued at all.
Now, what appears to have happened is that Lennart and/or Christian have got the wrong end of the stick and have thought that Phonon was being positioned as a multimedia interface for Qt and non-Qt applications. This seems to have got their goat for some reason, which might be that it stops tying an application to GStreamer’s interfaces and it is an inherently sensible thing to do considering Linux multimedia history and GStreamer’s ABI breakage. But, you know, let’s not let good development practice get in the way here. Non-Qt applications can certainly use Phonon should they so wish, but that is not its primary purpose and no one is trying to get everyone to use it.
In order to try and defend something that was never suggested in the first place, Lennart then uses the well-worked answer of “Oh, there’s no way you can use a C++ API because C is so much easier to bind to”. I’m not going to argue that one today (or try not to), because it is simply a response to something that was never suggested because of something they personally worry about. That’s a bit sad to be honest.
Well, the issue is irrelevant since it is a response to something that was never said or inferred, but I would suggest that if you are going to develop software, such as a desktop, that is inherently object-oriented from day one then you are probably going to need an object-oriented development technology from the ground up, otherwise you’re in for an awful lot of maintenance and fire-fighting. Telling everyone how many bindings you have are the least of your worries ;-). Go and ask the GTK developers how their manpower shortage is working out on that front.
Practical limitations of what? It was never suggested anywhere that everybody should just interface to Phonon – KDE, Qt and non-Qt applications alike.
Funny, as I wonder who attacked who, and over what. I would suggest that over-sensitivity would be creating a strawman argument that was never suggested and attack that position because of something else that you might be afraid of. That’s a bit…………….worrying.
Dealing with an API that looks, feels and acts the same as any other desktop API you might use and not having to worry about using GStreamer’s convoluted API, or tying yourself to a particular media framework that might change its ABI at any time and letting others deal with that problem, is going to be a lot more comfortable for application developers. Here’s me thinking that a standard development practice like that would be obvious.
If other application developers want a bed of nails for them and their users with multimedia then that’s entirely up to them.
Edited 2008-09-29 16:03 UTC
well, since i’m getting modded down for being honest, i might as well just indulge myself. today has been crappy enough that i just don’t care.
asiego is a comically abrasive personality who simply cannot take differences of opinion.
this is painfully clear.
that i’m getting downmodded for making an accurate observation relevant to the thread speaks volumes of the people who blindly align themselves with him. yes, follow… follow… follow…
he’s like the miguel of kde. oooh, burn. watch my score plummet!!!
his juvenile posturing is one of the key reasons users are put off from contributing to the kde project.
My guess is that you got modded down for the inaccurate second paragraph.
If a developer or ISV using Qt as their application framework, Phonon is quite a logical choice and not “pointless extra overhead”.
It is also wrong that it would be an overhead if you are not running KDE (assuming you in this case means the user/customer).
A Qt application is not restricted to KDE, e.g. see Skype or Google Earth.
So independent of whether someone agreed with your opinion regarding Aaron Seigo, they might have objected the inaccurary of that second part of that comment.
it’s NOT inaccurate. i never said you needed KDE for a QT/phonon app. but, if you’ve read any of my other comments on this story, you will notice that my main interest is pro-audio apps. there are currently TWO major pro audio apps that use QT, rosegarden4 and qjackctl. qjackctl is just a frontend for JACK, so doesn’t NEED phonon. i can’t speak for rosegarden, as i don’t use it.
i guess my point is that developers aren’t currently targeting QT for their pro audio apps. furthermore, there is no compelling reason to do so. the current paradigm is pretty much ALSA + JACK + very light widget toolkit. adding a further layer of abstraction would most definitely add overhead and potentially introduce latency into the recording studio.
on the consumer side, there are certainly apps that will benefit from phonon. amarok (once 2.0 hits) is a good example.
but, there’s nothing inaccurate about my statement. the current (and coming) pro audio apps on linux are not using QT as their main toolkit, so loading QT just for phonon would be extra overhead, and unnecessary. period.
It’s hard to imagine anyone arguing that one should drag in qt as a dependency just for Phonon, but it seems that perhaps some do. Though I suspect that what might really have some people in a tizzy is that the developers of current and “in the pipeline” pro audio apps have not chosen qt.
Edited 2008-09-30 00:58 UTC
Well, nobody is recommending to “load Qt just for Phonon”, that wouldn’t make any sense.
But claiming there is an extra Qt overhead for Phonon when already using Phonon is quite imaginative.
And your original psot had at least this part of inaccuracy: “… pointless extra overhead if you’re not running KDE.”
Whether or not I as the developer or my customer runs KDE is totally indenpendent for me as the developer whether using Phonon makes sense in my program.
If it just needs these kind of multimedia capabilities, using anything else would be pointless extra overhead.
you obviously have a language comprehension problem. i did NOT in any way say anything inaccurate. you’re simply twisting my words to fit your twisted logic. i said nothing about extra “QT overhead for Phonon when already using Phonon”. the exact opposite is true. i made it very clear that neither QT or Phonon are being used to any great extent in professional audio applications. pro audio applications on linux tend to rely on ALSA + JACK + a light widget toolkit. this simplicity improves responsiveness and latency in the recording studio. adding another heavy toolkit or sound api will only eat CPU cycles and RAM, which is never good for a studio. that is extremely accurate.
the reason why i said that it’s pointless extra overhead if you’re not running KDE is because right now, the KDE project is the only project using phonon! therefore, unless some developer is targeting KDE as their platform of choice for a pro audio app (which, trust me, they probably AREN’T) there is no incentive to deviate from the ALSA + JACK stack. doing so would only suck down resources for the end-user.
i have never put down phonon, or QT, in the many pages of this thread. my comments have been very specifically centered around a very particular niche: pro audio. phonon is NOT the perfect fit in this scenario. to misrepresent my comments as anything but that is preposterous.
don’t twist my words. it really irks me.
And this is your strawman argument, nobody is suggesting anywhere that you should use Phonon for pro audio(or video) applications.
Quite the opposite in fact, the Phonon developers, Aaron and every other Qt/KDE developer discussing Phonon points this out in a very clear manner. Those applications are the remaining 1% which Phonon was not designed for from the start, but for the remaining 99% Phonon is a very good choice.
Regardles of Phonon, without it Qt(and KDE) are still a very good choice for those pro audio and video applications. As seen in applications such as Rosegarden and Next Limit Technologiesรยขรโฌรโข RealFlow. And use in companies like Lucasfilm Entertainment and Walt Disney Animation Studios.
once again, twisting things to suit yourself. i KNOW phonon was never intended for pro audio work. i never said it was, or that anyone was trying to use it as such. as a matter of fact, it is *painfully* clear that that has been my point this entire thread.
the title of this story was “Guide Through the Linux Sound API Jungle”, if you can’t recall. all of my posts have been focused squarely on the pro audio side of the “Sound API Jungle”. i’ve been trying to do my part to help clear up some of the confusion, like… hmmm… why phonon may not be the best choice for pro audio work. but, in you fly, with your asiego-butt-kissing rhetoric, trying to paint me as some sort of villain because i was simply making a point.
and, NO, KDE is certainly NOT the best environment for pro audio work.
i’m so done with you. you’re like a brick wall. a brick wall made of dumb.
My first entry into this discussion, so the “once again” is a little premature I reccon. As for twisting, I simply pointed out your obvious strawman.
And here you present your strawman again. Nowhere in this tread or any of the links presented in this discussion have anyone been confused about that. Basicly everyone know that Phonon was never intended for pro audio work, so why keep raising the strawman?
As it seems like you have some knowledge about the subject of pro audio applications your usage of strawmen rhetorc and personal attacks diminish your comments.
No, only notice how you based your point arguing against some fictitious point created by yourself, e.g. a strawman. If you feel your usage of such makes you look like some kind of villain, you should perhaps re-evaluate your comments before you continue with personal attacks too.
Since there are no problem in writing a KDE application using backends suited for pro audio, like Jack or whatever preferred on the platform in question. And using an efficient GUI toolkit like Qt makes KDE a very good environment for such applications. That other KDE application utilize Phonon does not prevent such usage.
honestly, your tone was similar enough to the previous two responses to my posts that i neglected to look at your username. my mistake on that point.
but, i stand by my statements, and decline to further stroke your argument bone. my comments have, throughout this thread, been focused on one niche. there is no strawman, regardless of your fervent irrationality.
The VLC player also uses Phonon (with the VLC backend).
I would go so far as to say that there’s no problems with the current state of Linux audio.
Almost all open-source applications either use ALSA, or a sound daemon that doesn’t get in the way of other programs, or can direct their output through any sound system you care to name.
The problems arise when proprietary software gets thrown into the mix. I couldn’t understand the complaints about Ubuntu 8.04’s sound until I installed Flash Player. It’s proprietary software that interferes with Linux audio. Audacity, the last time I looked at it, also had problems due to its default use of OSS and recent option of ALSA. Maybe Audacity has been fixed since then, but Flash Player is still a problem.
If you want to blame someone for the audio problems, blame Adobe and Skype.
Ok, so proprietary developers should change their applications every 6 months to comply with the latest craze in the linux world?
How do you propose they develop a single version of their application that can maintained and tested easily?
Stability is what the linux world needs. Not yet-another solution to a problem that causes regressions for everybody the next 10 years until the next great invention in the linux world comes along.
And how deep did you dig your head in the sand to say this?
Me, I remember that a new API PulseAudio was introduced by many distribution recently, do you think those distribution did it ‘just for fun’?
I don’t think so!
Oh and the introduction of this new software introduced of course new bugs (I think that Ubuntu’s users where especially bitten by this)..
Considering that soundcards basically stopped evolving quite a few years ago (short of minor changes), it’s interesting to note that the software APIs for audio on Linux are still unstable (as evidenced by the introduction of PulseAudio)..
I would go so far as to say that there’s no problems with the current state of Linux audio.
No problems? It’s not long ago that I had to spesifically enable dmix plugin for ALSA if I wanted to enable multiple applications to use the soundcard simultaneously. PulseAudio fixed that, partially…I still have apps that fail to work with PulseAudio and then I have to disable that to get sound in those. Oh, and then there comes the issue that I have no idea how to set which sound card is the default and which is the secondary one. ALSA always insists the wrong ones as the default.
And if you happened to be a developer then you would KNOW there are issues…
Blaming it on proprietary software doesn’t make things any different. There are lots of examples of open-source software too that have issues..
I’d like to clarify what I said about “There’s no problems with Linux audio”.
Even on Ubuntu Hardy, the only time I have problems is with Flash. I admit I haven’t tried using Skype and Audacity since upgrading, but both those programs used to give me trouble in the past.
I’ve not observed problems with any other programs. 95% of open-source programs appear to work perfectly well with Ubuntu’s slightly-broken Pulseaudio. I can’t comment on other people’s sound cards or on multiple sound cards.
For the record, I’m a developer too, but I don’t work on audio.
That’s a typical answer from a selfish linux users who doesn’t care about all the other OSes around.
Technical considerations appart, ALSA is only for Linux, and totally unportable.
OSSv4 works on all possible Unix, not only Linux. It *is* the standard API for sound accross Unix. Heck, even ALSA had to emulate it.
It even works on BeOS and Haiku now (though we use our own API).
There is a nice thread about this article on the oss-devel mailing list:
http://mailman.opensound.com/pipermail/oss-devel/2008-September/000…
I’m not an audio/multimedia guru, but I know that there were a couple of counterpoints raised by Aaron Seigo related to the (tired) gstreamer vs phonon (???) issue, which was referred to in the article.
http://aseigo.blogspot.com/2008/09/linux-audio-layers.html
Follow up:
http://aseigo.blogspot.com/2008/09/strawmen-and-learning-from-histo…
Not to detract from the rest of the article, as I said I don’t consider myself qualified enough to do so, just wanted to point it out.
is that the old OSS just sucks. It’s impossible to emulate 100% accurately if you want mixing, even with a OSSv4-like kernel soft-mixer (it will inevitably add latency which apps can’t account for). Besides floating point mixer is not an option in Linux kernel, so the OSS emulation of ALSA is best it will ever get. Btw., it works just fine if you allow the OSS app to exclusively own the hardware. Just suspend PA and run your favourite OSS app (they should though add a mechanism to allow this automatically).
ALSA has a share of problem like mixer interfaces and few other (libalsa API is too complex and until Lennart’s blog entry it was impossible to know what to use as a safe subset that would work on PA, dmix and various other emulation layers). Otherwise it’s a very good kernel framework for accessing sound hardware (not to virtualize it!).
Modern stack should really look like what PA+Alsa is doing. A mixer daemon which talks to hardware exclusively and takes care of apps trying to produce sound simultaneously (Vista, OSX do that). Windows XP and earlier got a kernel mixer similar to OSSv4 way of doing.
I understand that there is resistance from BSD and Solaris crowd as they only have OSS (v3 and v4), so ALSA domination could mean that they are left out. For now applications should IMO implement both (ALSA safe subset and OSSv3. Hopefully there will be a library that will work on everything, I’m counting on libsidney, or maybe PortAudio when it starts working with Pulse.
Why can’t the Linux kernel support floating point in kernel space? It’s not all that difficult.
This is probably as good a place as any to highlight one of Lennart’s responses in the story comments:
Edited 2008-09-28 23:04 UTC
Sure, that’s why all of V4L2 lives inside the kernel ? =)
Yeah except this work only benefits linux, not all FOSS OSes. But of course there is nothing but Linux.
You’re inverting stuff here, it’s the kernel ppl who don’t even consider OSS.
QEMU virtualizes linux syscalls pretty well
Seriously, I’m sure there are LD_PRELOAD things around that do it (not like it’s very clean though).
Besides, There actually is a library I think but it only touches MIDI stuff:
http://mercurial.opensound.com/?file/e9875886bcf9/lib/libOSSlib/Rea…
BeOS has no problem doing floats in the kernel (though it has a clean native API at userland level, and a media_server that does the mixing, so I don’t even need vmix in OSS in BeOS.
Well that’s a design flaw in Linux.
Even BeOS and Haiku allow this.
ALSA is also fundamentally wrong w/r portability…
Noone stepped up to port ALSA to BSDs or Solaris. Their lack of manpower is something Linux devs don’t really care. There is plenty of linux-only code in kernel, and that code is a part of quick progress of the Linux kernel. Keeping OSS would be a stagnation of audio stack, happening just because other OSes can’t keep up.
OSS layer (on ALSA) is mantained in Linux and works. It sucks by design of the API, but implementation is as OK as it can be.
As Lennart said, it can’t be fully virtualized. PA tries the LD_PRELOAD trick (padsp) but it doesn’t work always and sometimes introduces more subtle playback problems.
In fact kernel-only API prevents any kind of userspace audio driver frameworks from being fully compatible with OSS apps, showing that OSS has serious drawbacks.
It’s Linux only now, but for which technical reasons couldn’t it be ported to other OS kernel?
Technical: I have no idea, but that doesn’t matter. It’s legally impossible. ALSA ist GPLed, most other OSes (like Solaris) are not.
“porting” ALSA makes no sense. In theory the API could be emulated but it is a horrendously poor API.
I dont’t believe that it is horrendous, especially when the expert in sound infrastructure says the opposite (quite well argumented). There are problems, but those are no fundamental flaws.
Porting ALSA might might seem pointless because of OSSv4 (another new API btw.), but a few years ago there was only the ancient OSSv3.
I’m not a developer, so I have no accurate idea what the real-world consequences of doing this would be, but… why not at least *support* both? Maybe not have both enabled at once, but make it a system-wide option. From what I understand, ALSA is a big mess and the newest OSS is nice and modern, and has pretty much got rid of any problems it once had that made ALSA necessary in the first place. Not to mention, OSS is cross-platform… ALSA is Linux-exclusive. Everything to me just points that OSS is the overall superior choice, and ALSA only remains because a bunch of people pissed off about licensing and release problems from years ago.
But to me, a user, I guess all that matters is that the sound works. Well, it does… kind of. Numerous times I’ve had various problems with the sound, and most recently in Ubuntu 8.04.1 I lost it completely until I rebooted. And this PulseAudio crap… it’s nice to have the ability to control the volume of different programs separately, but why does this require yet *another* program to do, complicating things worse? As far as I can tell, OSS supports this… by default… no additional packages needed. Nice and simple.
I personally would like to see a switch to, or at the very least more support for OSS in the various Linux distros. It really does seem to have benefits that ALSA lacks, and seems to be designed in a much more sensible way.
It seems to me that anyone making such sweeping claims had better have some facts and a pretty strong argument to back them up. You might start by actually describing, concretely, these “benefits that ALSA lacks”.
Edited 2008-09-28 17:30 UTC
Not the fact that many applications actually support ALSA (and not OSS), and ALSA actually supports many soundcards OSS doesn’t?
Don’t most sound daemons (and jack) support OSS just fine?
How many of you remember the days when ALSA was outside of the kernel and they only had OSS and then OSS didn’t support all the features of your soundcard so you had to download ALSA and compile it just so you would have sound at all?
I certainly remember that. I also remember when ALSA first became part of the kernel source tree. I actually rejoiced. OSS at the time sucked big time, and while ALSA had taken a bit more to set up, it was worth it.
Then came ESD which allowed multiple programs to access the sound hardware. It really wasn’t ALSA that disallowed this, but OSS.
I think a lot of the reason why people are so confused now on why OSS isn’t the standard Linux driver interface (which is really what it is, right? API is an Application Programming Interface, not a Driver layer… But then again I’m not a programmer so maybe there really is a problem with the API itself, but the drivers are quite good for every card I’ve used them with (Awe64, Soundblaster Live, Audigy, and currently an Audigy 2 Platinum (yes all the features of it work!)) is because they don’t remember why ALSA was created in the first place and why it became THE Linux sound architecture.
And for the idiot who said that there are no reasons to even have sound on Linux….. You missed Movies, games (yes there are Commercial and non-commercial, native and emulated). Not to mention what others have already said about doing professional work. A lot of those people used to use Atari STs. Which are probably far easier to set up for doing music studio work than any current platform is.
PulseAudio is the new fangled thing… why? Well some people had whined and complained about Esound for a terribly long time, even though there really weren’t any updates for it for a long time… which could only mean two things, that it did the job it was intended to do and no one needed something more, or it was unmaintained. I’m guessing it was a bit more the latter than former, but it was definitely in between.
ESD did everything I wanted it to, and for those that it didn’t, there was JACK which came out later. Personally I think PulseAudio is something that is unnecessary and Ubuntu tried to implement it too fast. Honestly, I can’t think of any reason why I have EVER needed to have different volumes for different applications. I only have ever needed to change volume of what game I’m playing so the music is less and I can just hear all the action.
Maybe I am just an old school Linux user and remember the nightmares of trying to manually set up my old ISA Awe64 card with the Soundfonts etc under OSS. And I thank all the great work of the Linux developers and others that have improved it a billion times over for the past 10 years.
What i don’t get is why we have sound server daemons at all – dmix supposedly does exactly the same thing – I mean, pulseaudio mixes multiple streams together and sends them to an ALSA plugin that mixes multiple streams together. It seems wholly redundant. Either dmix works properly , or it should be worked on until it does work.
I can see some role for pulseaudio as a cross-UNIX compatibility layer, but I feel if that if a cross-UNIX audio API is to be defined and used, it should be implemented in libalsa, not as an additional daemon.
Personally, I think JACK functionality should also be exposed via the ALSA API, and when an app that uses ALSA’s JACK wrapper is run, dmix should re-initialise and connect itself as a JACK client so other applications sound continues to work. When nothing except dmix is using JACK, the system should re-init with dmix running on the hardware to enable power saving features lost when JACK’s callback loop is running.
OSS-emulation should also run on top of dmix, and direct hardware access to the sound card should be denied by default. – There should be a way to access these features, but apps using these features should fail LSB/HIG compliance since they will never play nicely with others.
I think i’m wasting my time posting this however, i doubt linux audio will ever be integrated into a single, seamless API, despite the obvious benefits in simplicity and consistency with this approach.
some people see network transparency ( the ability to route data to another machine) as a top priority and a vital feature
then a sound server to which networked as well as local audio client applications cand send their sound samples for ( possibly concurrent) playback, is the logical thing to come – especially on *nix, where the socket is THE fundamental ipc primitive
problem ( for Lennart ๐ ) is, the requirement of allowing sound from more than one local application at a time to be played on a local audio device, (a simpler at the same time more common in a consumer desktop environment) does not necessarily require a server daemon to be fulfilled –
remembering
that an operating system kernel can be approximately summed up as “a privileged component that can interact with physical system resources, abstracting them for running processes and pooling them across running processes in a secure and safe way”,
that a macrokernel like linux does this at the file level (i.e. presenting devices as files and treating them as such access control-wise, and implementing file access policies internally ),
that (MUCH) more complex command stream multiplexers (eg drm) already exist in the kernel,
and that mixing pcm streams is not (IIRC) so different from ADDing vectors of fixed point values,
one might come to the conclusion that having inter-application stream mixing performed in the driver’s “upper half” is not that “fundamentally wrong”, from a conceptual point of view at least (sample rate/size conversion is a different matter, but there’s no true need to perform it together with inter-application mixing – the single application could mix its own audio streams internally, and/or convert them to a sample rate negotiated with the driver, before sending them for output)
alsa people may tell you that dmix was intended for mixing “at a lower level” than the one the sound server works – but yes, redundant they do really seem
as a side note, it’s interesting to see that OSSv4 support audio redirection…
probably and sadly, people would complain for the resulting “lack of choice” then …
Edited 2008-09-29 01:38 UTC
On network transparency – why not simply allow a handler to register to receive a copy of the audio stream from alsa lib which it can then stream across the network? – i don’t see why you need a higher level component that needs to intercept all audio streams just for this.
http://www.chaoticmind.net/~hcb/murx/xaudio/
That kind of thing, implemented as an X.org extensions and pluggin directly into ALSA, seems saner than an additional client/server system
And, speaking as a linux audio developer, I don’t care what OSS does or does not do. It’s dead on Linux, and isn’t coming back. Personally all I want to see is better centralisation of audio functionality in ALSA and libalsa.
Yeap, stick with ALSA and integrate decent JACK functionality into the core of Linux desktop audio.
Have a simple interface for most users and an advance one for those of us who want professional capabilities.
Pulse Audio is a waste of time.
This is what happens when politics drive technology decisions, and almost every problem I have encountered in software development has this as the root cause.
Audio is the ugly stepchild of computer media. Most audio hardware STILL hasn’t moved on from MIDI to USB|Firewire, which was also the only API EVER to be removed from Java SE, and Vista ditched HW accelerated DirectAudio for a new C++ API. God knows what I’ll encounter as I attempt to develop advanced audio apps for OpenSolaris.
Sound is just not treated with any respect or consistency by the majority of developers it seems. What’s doubly frustrating is that audio is so VERY simple conceptually. All I want to do is route and filter digital streams and choose which analog sphincter they poop out of. Not that difficult.
I’m currently using GStreamer because like a mountain, it’s there, and I’m looking into using JACK. But I have little idea of what the UNIX|Linux audio API landscape actually looks like, and it’s still hard to asses despite all the articles written about it.
Just use the Haiku Media Kit ๐
with Ubuntu 8.04 I lost the mixer. I installed OSS4 and it now works perfect