Audio Server Strategy Idea Braindump

[Jeff Waugh <jdub perkypants org>]

Hey,

Quick summary of an audio server strategy idea that came up a few weeks ago
with some linux-audio-clueful friends:

  * Encourage distributors to take up jackd as the local audio server of
    choice, as it gives the 'linux desktop platform' story an advanced audio
    API for multimedia and gaming use.

  * "Fix" esound to concentrate on two tasks: 1) talk to the local jackd and
    2) talk to a remote esd. jackd is very demanding of its clients, so
    having a simple esound replacement that handled all of the complicated
    stuff and provided a simple "play this audio now" API would make live
    easy for simple tasks.

  * We end up with two 'foundation' audio APIs (jack and esound) and two
    daemons (jackd and esd, with esd talking to jackd or a remote esd).

  * Would it be worth handling network sound device configuration at the HAL
    level? Some interesting thoughts there. Certainly need better GNOME
    config support for this via GConf, yada.

Dealing with this in GNOME:

  * Sneak audiofile out of the GNOME devel platform. No one else uses it
    directly anyway, so it wouldn't really be missed or a serious bincompat
    problem.

  * Fix up esound, perhaps a rewrite using gstreamer, but keeping bincompat.
    Too hard?

I know this is a perpetually frustrating line of conversation, but worth
bringing up again to think about for 2.8. I'm not attached to this idea,
just want to put it out there.

- Jeff

-- 
GVADEC 2004: Kristiansand, Norway                    http://2004.guadec.org/
 
     "First: This is not a race." - Jody Goldberg on the Free Software
                                  desktop