Re: [linux-audio-dev] Re: timing issues in a client/server enviroment

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Re: timing issues in a client/server enviroment
From: David Olofson (audiality_AT_swipnet.se)
Date: su loka   10 1999 - 14:03:23 EDT


On Sun, 10 Oct 1999, Kai Vehmanen wrote:
> On Sun, 10 Oct 1999, Benno Senoner wrote:
>
> >> or more sample implementations is a great idea, but please don't
> >> anyone go off and think they are writing "the Linux Sound System".
> > I agree on the fact that apps should be able to do their own pugin hosting,
> > but sooner or later we will need some engine which allows routing and
> > integration of simultaneously running audio apps,
>
> I don't want to sound pessimistic, but it might be better to start
> with something simpler. For instance, I'm currently using ALSA's
> loopback device quite successfully for routing audio data between
> audio apps. With a few improvements/additions, ALSA's flexible
> mixer design combined with ALSA-lib/driver functionality would serve a lot
> of purposes. And what's important, these things exist and are ready
> for use, now.

Sample accurate sync between apps? Yes, that can be done in the
protocol, and that's one of the points with the Multimedia
Communication System. You'll be able to do what you're doing now,
you'll be able to do it about the same way but get real sync with the
new system, or you can use plug-ins in a central engine, if you want
the lowest possible latency. (The engine might even be running under
RTLinux if the user is a latency freak! :-)

Breaking and replacing the currently existing APIs is not the goal,
IMHO. Replacing the underlying implementation with an infrastructure
that can provide *both* the old and the new Apsis with the best
possible performance is, in the longer perspective. If we manage to
integrate the low level communication system with ALSA, we could get
very close soon.

However; the plug-in API first.

Just keep in mind that it must fit nicely with the communication
system, or we'll end up with little more than yet another "standard",
that inherently generates clumsy and inefficient implementations.

//David

 ·A·U·D·I·A·L·I·T·Y· P r o f e s s i o n a l L i n u x A u d i o
- - ------------------------------------------------------------- - -
    ·Rock Solid David Olofson:
    ·Low Latency www.angelfire.com/or/audiality ·Audio Hacker
    ·Plug-Ins audiality_AT_swipnet.se ·Linux Advocate
    ·Open Source ·Singer/Composer


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST