“This document attempts to give a sketch of the names and relationships of these technologies and projects, and a glimpse into their status and development. Some technologies have never proved themselves, and/or have been rendered obsolete by later development and are available primarily for legacy code. This document attempts to clarify much of this natural evolution and market selection.” Read the X roadmap from Jim Gettys and await a long and interesting interview with freedesktop.org members on Monday, here, at OSNews.
Open Source Desktop Technology Road Map
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Excellent article – this is quite technical and meaty, but very understandable, and actually helped to clarify lots of things in my mind. It’s hard to remember all these buzzword technologies and what they all do, but this roadmap makes a nice reference to the whole spectrum of desktop libraries.
I’m just kidding, I’m not a developer so a lot of this was a bit too technical for my understanding so if anyone wants to put it in laymans terms for me that’d be great thanks. What I think I got out of it was that they wanted to get rid of legacy stuff and make something new. The part I’m most concerned with is the artsd and esd sound daemons, do they want to replace these or keep them around? JACK sounds nice, why haven’t more applications or any desktop environments used that by default?
*nix heads can not aggree on nothing 😎
If I want to write a commercial app, which sound API should I use to make a business case ?
which sound API should I use to make a business case ?
“business case”… LOL… why don’t you not develop your app at all, and just go back to maximizing shareholder value while increasing ROI and B2B integration with end-to-end J2EE solutions in the e-Commerce .com marketplace?
M$ get over 400 bucks for every 100 dollars they spend on windows investment – that is a good ROI.
Look at Redhat, they quit the Redhat linux all together and switched to RHEL for per seat licensing – a lesson learnt on a sinking boat 😎
If I want to write a commercial app, which sound API should I use to make a business case ?
Your app should be able to use any of them. Welcome to choice.
Most will choose to use none of them at all.
more choices equals to no standard if there isn’t a common API
Most applications are able to use any of the sound deamons or mechanisms, esd, artsd, oss, alsa. Any application worthy of being used should support either of them. An application that doesn’t is categorically rebuked by the community.
touché
—-
Great article-I just wish it was possible to get a clear look at what the future of X is going to look like taken together-ie. not just some info about XCB/XCL but how XCB/XCL,with its potential for significant enhancements, together with cairo, which promises a PDF-like display system perhaps to be implemented in Gnome Canvas, and together with Xserver and its new XDamages, FixesExt, CompositeExt extensions. It seems likely that by the end of next year(2004) we will be looking at a significantly different visual/graphical landscape-of course it is still a question as to whether Keith P. & etc. can convince the producers of closed-source binary drivers(Nvidia) to jump on the band waggon and support the new developments.
Now take this together with the code-bounty initiative for Gnome that was just announced. The upcoming 2.6 Kernel and its HAL, perhaps enabling a D-Bus based hardware detection and configuration-once of course when the producers of closed source binary drivers (fritz) start rewriting the modules for 2.6.
—->The upcoming 2.6 Kernel and its HAL, perhaps enabling a D-Bus based hardware detection and configuration-once of course when the producers of closed source binary drivers (fritz) start rewriting the modules for 2.6.<—
should read-
The upcoming 2.6 Kernel an it’s HAL, perhaps enabling a D-Bus based auto hardware detection and configuration –yet again on fully realizable when the producers of closed source binary drivers (fritz) start rewriting their modules for the 2.6 kernel.
Jack rules. Seriously.
There are a few places that I can point to on Linux, and say it has a better solution than is available on Windows. Jack is one of them.
Under Windows, the only thing close to it is Steinberg’s Rewire, but I belive there are actually less Rewire enabled apps than Jack ones.
Either people will go for daemons like arts, esd etc, or they will choose the solution that is capable for both everyday apps and serious pro audio, without compromising either. Jack also has transport capability so you can sync apps together at sample accurate level.
So, not many distros offer it as the default install, and not all apps support it yet… But without it, Linux is dead in the water as a media OS. With it, only the OSX audiounits system offers comparable capability. Just my 2 cents.
“Most applications are able to use any of the sound deamons or mechanisms … ”
That will be a support nightmare.
“An application that doesn’t is categorically rebuked by the community….”
rebuked by the few in the minority is a better phrase.
Just use the gstreamer framework
http://gstreamer.net
Nuff’ said
Please back on topic now. This has nothing to do with the subject.
JACK hands down. http://jackit.sf.net
-fooks
“If I want to write a commercial app, which sound API should I use to make a business case ?”
Open Sound System. Can’t you do at least a little research before assuming there’s no standard?
“That will be a support nightmare.”
Then only support a few of the most common configurations.
What, was that too hard for you to figure out?
haha, three different answers. Just as usual in the linux world where absolute choice goes before everything else.
Well, what are your needs? A network system for providing sound to lots of thin clients, where drop-outs and high latency are expected, or a high performance latency critical system for integrating multiple apps on a single computer where dropouts are unnacceptable?
There are many answers because there are many unanswered questions….
“Open Sound System. Can’t you do at least a little research before assuming there’s no standard?”
Well, ALSA will be the standard in Linux kernel v2.6, while OSS is in v2.4. OSS in v2.4 is a pretty old version (3.7.x or something), and it supports a lot of cards – some which ALSA doesn’t support. However ALSA has more functionality, is under development, and is Free (speech). Newer OSS versions aren’t Free (speech) nor free (beer) but could be a solution for those who have an exotic card which ain’t supported. OSS (the old, Free version) will still be in v2.6, however they won’t be the first choice; OSS is marked as deprecated.
I’d go for ALSA, seriously. Why? It is under development and almost to version 1.0. It has more functionality than OSS (especially some cool stuff for musicians) and it supports less cards, but since its under development (unlike OSS, which is under development, but is non-Free and non-free) it can become better. Most people wouldn’t want to pay for getting their soundcard to work with less functionality than a Free version, and ALSA will be the standard.
ALSA provides backwards compatibility with OSS. One can use ie. XMMS with OSS output plugin together with ALSA and OSS emulation enabled in ALSA. However, for XMMS there’s also an ALSA plugin.
Then there are also quite a few programs, mostly for people who’d like to compose music, which allow only usage with ALSA. Using OSS? Bye! Forget it. And i’ve already found quite a few _nice_ programs.
So install ALSA, fire up JACK, and start the fun!
Just as usual in the linux world where absolute choice goes before everything else.
I’d rather go for choice (i.e. freedom) than having no choice (i.e. dictatorship).
A dictatorship is more efficient than a democracy. Trains got to the station on time under Mussolini. And yet, even though a dictatorship is more efficient, most people still want democracy. Why should it be any different in the OS world?
Choice is good.
Now, can we please get back on topic, which is the X roadmap? I’m happy to learn that the Composite extension is part of it, and that there is continuing development on it. Now, if they could provide what we’ve seen with Looking Glass…
“A dictatorship is more efficient than a democracy.”
Why?
Because in a democracy, you must debate things. Elected representatives will weigh pros and cons, discuss amendments to bills, have comittees examine all aspects of a situation. Debate is part of democracy, and an elected assembly that correctly represent its constituents will not rush into things but will debate how things should be done.
Dictatorship rule by decrees. You do what you’re told, otherwise you’re either put in prison, tortured or just shot in the head. A dictatorship is more efficient in the way that things get done quicker, with a lot less discussion and debate (none, in fact). But it does not make for a just or free society.
Efficiency is a nice thing, but it is not an essential thing. Think of it as a bonus. Democracy, on the other hand, is a necessity. The fact that it is less efficient by nature than a dictatorship doesn’t mean that it is less desirable. A less efficient political system is the price to pay for democracy, but it is a price that is well worth paying in the end.
There are two catagories of sound apps: pro apps, and consumer apps. They have such different requirements that the same audio API really can’t satisfy them both. In order to get the best performance, you have to use a call-back based scheme, but that’s a pain if your app just wants to play “beep.” If you need pro audio, you use Jack, there are really no questions about it.
If you’re writing a different sort of app, then you have some choices to make. The reason that a sound server hasn’t been decided yet is that none of them are really sufficient for every case. Jack would be great, but its not network transparent. aRts has high latencies. esd just sucks. MAS isn’t mature yet. Once the sound servers get up to snuff, then things will settle down. Until then, the choices aren’t as bad as you’d think at first. If you’re writing a GNOME or KDE app, you can just use whatever sound services they define in their framework. Since most Linux desktop software is still OSS, there are a number of different apps for each catagory anyway, so having different apps for different desktops isn’t a big deal. If you really want to be desktop agnostic, then use something like PortAudio, which abstracts over all of these. Yeah, there is a little bit more latency this way, but for an app to yell “beep!” how much performance do you need? Remember, if you were writing a pro app, you’d be using Jack
With kernel 2.6, it really doesn’t matter which sound system you choose. ALSA will happily mix streams from all of these sources, so you’re not going to end up with the pre-ALSA problem of GNOME apps not being able to play audio in KDE or vice versa.
Its not just that. Historical experience shows that the intense focus of dictatorship can seem efficient at first (the Soviet unions centralized economic plans) but ends up being less efficient in the long term. So far, the “anarchy” of a free market is the most efficient system we have come up with for the long term.
True, dictatorship are not sustainable in the long-term. However, one must make a distinction between “socialist” dictatorships like the Soviet Union, and “capitalist” dictatorship like Nazi Germany. In a “capitalist” (or at least capitalist-friendly) dictatorship, economic development is not managed by the government, but rather by a series of corporations hand-picked by the dictator. This makes for a very efficient system, especially when compared to a “socialist” dictatorship which tries to manage everything in addition to holding supreme executive power. It’s just not feasible.
Note that economic systems and political systems are independent, to a degree. You can have a democracy that has a free market, or a democracy with a heavily subsidized economy (such as the U.S.) or a democracy with a tightly-controlled market – it depends on the will of the citizens! Similarly, you can have a dictatorship with a free market (where corporations have a lot of rights, but individuals have few) or a North Korean-like Stalinist state where freedom doesn’t exist, whether it is for capital or individuals.
But this is a different debate. I was not talking about economic efficiency, but rather political efficiency. Let’s say you need to pass a new law – no doubt a dictatorship will have it done quicker than a democracy will. But chances are the law voted by the democracy will be fairer and more just than the decree promulgated by the dictatorship…
This is quite a fascinating discussion, but it is quite off-topic. Thus that’s all I’ll say on this subject as we may get modded down.
Uhm, Hitler bought all the companies in the country when he came to power. Both communists (i think they were rather anarchists, but ok) and social democrats were put to silence. The fact Hitler came to power was a reaction to capitalism -because of poverty- and included a ”black sheep” theory. After Germany got blamed for WWI, the Germs hated the French and seeked for revenge. The Germans saw how the rich in their country got their business done; most of them were Jews; thus Jews became the black sheep.
A good document this i’d recommend is this one
http://www.bofx.net/fascism.pdf
Quick and Good do not always combine very well. I think a dictatorship can decide various things quickly, but not well, since it isn’t known everyone agrees with such new law. In fact a small group of people decide over a big group. In a ”democracy” as most humans know the definition, the person(s) who decide are chosen. I don’t call that very ”democratic” (demos = people cratic = will/power). It would be way more democratic if ideas were chosen and if people could actually see what government organisations like FBI/NSA/BKA/KGB/AIVD and such. In fact, any organisation or company. But they don’t allow, because they don’t trust you to see it. One can’t even vote per-law wether s/he agrees or not. A lot of money is needed for a campaign. You call that democratic? Sorry, i don’t. I call it chosen dictatorship, and time over time i see political parties in governments are more in power than others. Sometimes even for many years. Or there are only 2 big political parties while the rest have no chance. They can do about anything they want… with the people’s opinion not mattering except when it is voting time; then every politician is nice and gentile. When votes would occur more, on a different time base than 4 years, there would be more pressure on the politicians to do what the people want, and it would be a bit more democratic. Like for example, the ”referendum” (which isn’t even binding here!).
Let’s say there’s no law needed, because people discussed the issue based on consensus. It wouldn’t go quick, but it would be good
funny thing is, this is about how i see it goes in the Free software community, because the laws of copyright are very Free. Because of this, there is a lot autonomy, and i see a lot problems are caused because of ”legal” issues. It doesn’t go quick, but it does go thoroughly.
I just ran XMMS remotely via SSH and it made me think. What if i could have somehow get the sound at the local box? Network support in _ALSA_ would be an awesome improvement. Then, it doesn’t matter wether JACK has it or not. Or should it be done by remote mounting a /dev ?
ESD + ALSA do the job mostly here. Sometimes JACK (+ESD) + ALSA.
I just ran XMMS remotely via SSH and it made me think. What if i could have somehow get the sound at the local box? Network support in _ALSA_ would be an awesome improvement. Then, it doesn’t matter wether JACK has it or not. Or should it be done by remote mounting a /dev ?
I’m not a kern developer, but if I remember correctly from my fiddling with netbooting, mouning a /dev/ file system doesn’t do automagic network transport of the /dev/ devices. This is because the /dev/ devices are simply descriptors for kernel major/minor devices.
From my own experiments, I’ve essentially given up on getting network audio for the moment, and stuck with running various programs on the box with the sound device and running webservers and exported X sessions.
Ok, you’re right, i should have named it in greater extense. I’m not a kernel developer either. But imo would be cool when one does cat /dev/urandem > /dev/network/theboxnameistara/sound/dsp (just an example) it would work on the other system (taken that permissions are fine).
Therefore the kernel must know that such device points to a network-sound. So then, the kernel talks to a local daemon, which is authenticated (for security reasons) with another daemon. Encryption of authentication or authentication + data come in mind then. The other daemon just needs to access /dev/sound/* and you’re all set. A nice option would be to keep either the remote and local sound in sync or various remote in sync. Sound is currently too much an individual thing, while it could be done otherwise. Imagine a concert using a GNU/Linux cluster to send data to their boxes!
I’ve tried this with XMMS + LiveIce + IceCast, giving ”my whole house” music, but that didn’t work very well since they weren’t in sync. It does work when i plug in a cable directly on the soundcard of the box which plays music, while the box is actually ”somewhere far away”.
For network transparent sound try MAS. It works quite well.