Desktop Architects Meeting 3

7:09 pm wengo

I’m in Portland for the Desktop Architects Meeting 3 at the moment, representing the OpenWengo project.

It’s been good – although the presentation sessions have been numerous, and have over-run, eating into break-out session time (which is what everyone is really here for).

Yesyerday, I was at the sound break-out, with people from Helix, Jack/ALSA, RedHat, Fluendo, LTSP, LSB and others. It was a good session, and took the right tack. We talked about what was needed to create an environment where we could solve the sound problem on Linux.

For those who aren’t aware of the sound problem on Linux, the problems
are that you have about 6 or 7 sound APIs you can develop against, and none of them work nicely together; all of them support some subset of the use-cases that ISDs creating sound apps need, and those subsets all overlap in some way; there is no agreement on what the scope of a sound API and sound system for Linux should be.

The end result for the user is that when you go to a web page that includes flash, your music player stops working, or your browser freezes up until your music app quits, or any other number of issues that are created when different apps use different sound APIs.

It should be noted that pretty much everything is possible right now – with at least one API.

So the first goal is to work out that scope – agree on use-cases that should be enabled in the basic sound API, and work out how we can move from where we are now to a place where all of those use-cases are possible with a high-level sound API.

The plan for that is to get all of the actors involved together on a mailing list, including application developers, platform developers, distributions and low-level sound APIs. We need agreement on the sound story – the use-cases and scope, and have at least one face to face meeting to work out how to go from talk to action, and hopefully between now and next year, we should have something which ISDs like us can use and know that things will Just Work.

I unfortunately missed a second break-out on packaging, installation, dependency management and upgrades – choices are horrible.

A second set of break-out sessions is planned today – looking forward to going to an ISD session, if we have another one.

One Response

  1. Tim Janik Says:

    The issue of multiple sound APIs has been noted before, here’s a paper Stefan Westerfeld (aRts author) and me wrote over 3 years ago to adress the issue:
    Back then, we started the CSL project to aim at a common layer, but later halted it because at that time it looked like PortAudio could become the new defacto standard. PortAudio has since not made notable advances under linux though and seems to be in general neglect, so the basic need CSL was meant to fullfil still exists. However, these days, most systems at least offer an ALSA API, and the next most promising candidate to help with unification is PulseAudio: