Re: Audio Server Strategy Idea Braindump

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

Hi Jeff,

(consider this as a reply to Thomas, too).

On Fri, 2004-03-19 at 03:15, Jeff Waugh wrote:
> > 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.
> 
> I kinda agree with Thomas on this point; it can probably just be extended.
> We do need to keep API/ABI compat, and there's really no point talking about
> GNOME 3.0 yet, especially as an excuse. :-)
[..]

> > 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.
> 
> The Esound API doesn't need to be dropped, IMO, just extended.  For a
> lot of applications, the esound api is fine.  For a bunch of others, the
> API can extended to give them what they need.

That's what I mean. The *current* ESD API is bad. Sure, for GNOME-2.x,
we're tied to this cruel thing called API/ABI stability, but I want to
think beyond that. Not in code, but in planning and ideas. The ESD API
setup is good. And we'll need it in 2.x. But beyond that, do we want two
servers?

I don't think so.

My idea is to keep ESD. Let it die, silently. It's allright. I agree
with Thomas that the ESD API is fine for numbers of applications. One
thing where Thomas is wrong is that 5:1 sound can be added, we need to
change the API for that in an incompatible way. Anyway, other things can
be added without breaking stuff badly, and the API is a good reference,
too. It's what apps want. Except the ugly read()/write() - I'd rather
have a audio_read()/_write(), one that wraps and (in theory) allows for
DMA, non-copied, non-socketed audio transferring into the jack-provided
buffer.

How? By wrapping Jack in libgnome!

Yes, I want an API similar to ESD (but better - we've learned from the
past) in libgnome. Apps will link to it anyway, so who cares. Maybe we
want a separate package (dse or so) in the end, dunno. Anyway, you get
the point. It doesn't mean we rewrite-from-scratch, it simply means we
will break with esd as it is right now. A rename might make people
believe we've improved. And parts need to change (*no* two sound
servers, *no* POSIX write()/read() hacks, etc.).

I don't care how we write it, based on GStreamer or based on the current
codebase. That's peanuts.

> Sure, if we can reliably talk to jackd via libgnome without another daemon,
> esd ends up fairly irrelevant - except for the network stuff. There's a few
> jackd network things going on, but I'm not sure if they'll be appropriate or
> dynamically configurable. We'll have to look into that, too.

Needs thinking. But should be possible. Let's ask the Jack people.

Ronald