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."
Post a Comment
Member since:
2006-11-18
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
Member since:2005-07-24
Member since:2005-11-11
Member since:2007-02-17
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.
Member since:2005-07-08
Member since:2006-05-02
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.
Member since:2006-01-17
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?
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.
Member since:2005-07-06
"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 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.
Member since:
2006-02-19
Member since:
2007-06-28
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.
Member since:2008-07-15
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.
Member since:2008-07-15
Member since:2007-06-28
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
Member since:2008-07-15
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.
Member since:2007-06-28
:) 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.
Member since:
2005-07-06
...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).
Member since:2005-11-13
Member since:
2005-07-06
Aasron Seigo's reply:
http://aseigo.blogspot.com/2008/09/linux-audio-layers.html
Member since:2007-02-17
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.
Member since:2007-06-28
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.
Member since:2005-07-24
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
Member since:2005-07-06
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:
Unless your focus is only KDE in which case KNotify might be an alternative although it has a different focus.
KNotify supports multiple backends for audio playback via Phonon. Both APIs are KDE/Qt specific and should not be used outside of KDE/Qt applications.
Phonon and KNotify should only be used in KDE/Qt applications and only for high-level media playback, resp. simple audio notifications.
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
Member since:2007-06-28
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.
Member since:2005-07-07
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.
Member since:
2008-05-26
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.
Member since:2005-07-12
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.
Member since:2005-07-06
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)..
Member since:2006-02-15
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..
Member since:2008-05-26
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.
Member since:2006-09-30
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...
Member since:
2005-07-13
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.
Member since:
2006-01-17
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.
Member since:2006-01-02
Member since:2005-07-24
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
Member since:2006-09-30
"OSS4 does a lot of signal processing (resampling, mixing) in the kernel. That is a big no-no, it's verboten in the Linux world. The kernel is supposed to include drivers, not processing algorithms.
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...
Member since:2006-01-17
Yeah except this work only benefits linux, not all FOSS OSes. But of course there is nothing but Linux.
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.
You're inverting stuff here, it's the kernel ppl who don't even consider OSS.
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.
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).
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.
Well that's a design flaw in Linux.
Even BeOS and Haiku allow this.
"
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.
ALSA is also fundamentally wrong w/r portability...
It's Linux only now, but for which technical reasons couldn't it be ported to other OS kernel?
Member since:
2006-12-05
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.
Member since:2005-07-24
...
From what I understand, ALSA is a big mess and the newest OSS is nice and modern,
...
Everything to me just points that OSS is the overall superior choice,
...
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
Member since:2005-07-24
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?
Member since:
2006-01-10
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.
Member since:
2006-01-24
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.
Member since:2006-03-01
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
Member since:2006-01-24
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.
Member since:2006-09-15
Member since:
2005-07-06
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.
Member since:2006-09-30
Just use the Haiku Media Kit ;-)
Member since:
2006-12-30
