Future prospects of the Linux Desktop – Desktop Architects Meeting 3

Tux
I already blogged about the FSG face2face meeting from December 4th till 6th, but completely missed another meeting happening there: the Desktop Architects Meeting 3, short DAM 3.

And yes, it looks like quite a lot of people who attended the FSG face2face summit also attended the DAM, what a surprise😉
Today fortunately the German IT news heise.de posted the news that the slides of this meeting are released to the public. Btw., have I already said that I’m *really* happy that heise.de exists? It already happened quite often that they reported about important IT news which all the other media missed (like slashdot, osnews, etc.).

Anyway. The slides are straight forward and progressive. The current problems identified are hardware support (in the terms of writing drivers if you are an ISV), cross desktop development (the area Portland addresses) and Multimedia.
While the first two were not surprising at all, the fact that software installation was hardly covered at all is confusing to me, but that is maybe because there was a software meeting just a day before. But the multimedia part was also surprising: sure, that there is a DRM problem and that Linux has some codecs problems is obvious, but there was also a problem identified with Audio:

  • Audio on Linux sucks.  Developers don’t know which interface to use.
  • No clear vision from kernel, distros, or application developers.
  • Problems: CODECs, configuration, multiple apps through HW device
  • APIs needed for integrating audio applications
  • No venue to discuss audio
  • Professional vs consumer

I thought the audio situation is quite clear? I mean, we have Alsa, and OSS is officially obsolete (for Linux at least), so where is the problem?

But I’m not an audio guy, and I think I miss the point here. And since there are good plans to get rid of the problem (talking to ISVs, making a face2face audio summit, create use cases) I’m confident that we will see a lot of improvements in the next months.

Last but not least I want to quote the solution to DRM favoured by the meeting: Hoping/waiting for DRM to die. I like that!

5 thoughts on “Future prospects of the Linux Desktop – Desktop Architects Meeting 3”

  1. I’m not an audio guy either, but It’s quite right there’s a lot of buzz words which aren’t very clear to developers. For instance, try to give a definition of jack ? phonon ? esd ? alsa ? If I’m a developer, I don’t want to learn all of these things, I just want my application to produce sound. So I can understand the confusion.

  2. why don’t they just use gstreamer? Doesn’t it solve all those problems, eg., codecs through the plugin archictecture.

  3. gstreamer is an interesting attempt – however, at the moment it is not at all in a shape to provide professional audio editing with real time capacities. There you still need jack.
    Also, gstreamer is not yet in a shape where you can totally rely on – therefore for example the Adobe flash plugin uses Alsa.

    gstreamer first have to prove that it is worth it fully focusing on it.

  4. gstreamer is not anything like ALSA.

    gstreamer is designed to allow you to connect various components (codecs, filters, input / output devices, and so on) to do something with media.

    ALSA is the audio input / output API. Basically, you can use it to pull samples from an audio input, or shove samples into an audio output.

    The distinction exists on all operating systems – a Mac has Quicktime for codecs and filters, but CoreAudio for raw audio input / output. Windows has DirectShow for codecs, but has ASIO, DirectSound, various kernel-mode streaming APIs, WDM APIs, Vista’s version of the WDM APIs, and whatever the replacement for DirectSound is called (XAudio, or something?) for audio I/O.

Comments are closed.