Re: Audio Server Strategy Idea Braindump

["Ronald S. Bultje" <R S Bultje students uu nl>]

Hi Jeff,

thought about this for a while and thought I'd share some ideas...

On Thu, 2004-03-11 at 05:48, Jeff Waugh wrote: 
>   * 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.
Had to think for this for a while, but I think I like this. Jackd is
definately the audio server of choice for the pros, even if only because
they wrote it as such. It's probably worth adopting it so that we can
say that we have one shared daemon that we all like.

>   * "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.

Here's the part that I don't like. I know about GNOME API stability in
the D&DP and all that mess. But this is not the solution, at least not a
long-term one. You've just said you want to drop ESD. Then drop it!
Everyone wants to drop it anyway, why would we keep it in. Because it's
easy? Nah.

This basically means that you stick to some of the disadvantages of ESD:
* it provides a far-too-simple API for advanced audio handling.
   - It has no knowledge over multi-channel audio apart from stereo
     (5:1, anyone?).
   - It provides no API for getting latency or queue timings, so any 
     form of exact A/V sync handling (like we love to do in GStreamer)
     can only be accomplished using ugly hacks. Even then, only
     marginally.
* ESD actually loves to convert everything you send to it to stereo, 
  44,1kHz, 16bit. You'd probably fix this, but you didn't explicitely
  mention that so I thought I'd mention this. Just so you know. :). 
  Attaching jack as an output doesn't fix ESD's own issues.
So sticking to the ESD API actually means that we will face some of the
problems that we're now facing, too. For exactly that reason! So it's
probably not a very good idea.

Wait for GNOME-3.0 if you have to because of the D&DP guidelines (like
API/ABI stability). And then kick out ESD. Nobody will care. People will
be happy.

The API point is the only reason. Indeed, jack's API is extended, but
hard (especially the callback audio pickup/delivery is sort of
non-intuitive for persons new to the topic). So we need to wrap it for
the layman's use of it. But not via ESD!
Why don't you ask some audio-clueful person to write a short wrapper API
for you in libgnome? There's probably persons over here that can do it,
too.
Or, but that's probably GNOME-4.0 material (when it has prooven
stability and so on, "ready for D&DP"), use GStreamer (it has a jacksink
element)? GStreamer could then take over the libaudiofile tasks, too.
And you'd have instant Ogg/Vorbis support which was requested several
times on gnome-desktop-devel  
Jorn Baayen (former Rhythmbox maintainer) wrote patches one or two years
ago to port GNOME's audio code over to using GStreamer, I guess those
are worth looking at when time's there.
So I guess my main suggestion here is to choose something different from
ESD as your wrapper API in GNOME.

Ronald 

-- 
Ronald Bultje <rbultje ronald bitfreak net>
Linux Video/Multimedia developer