Subject: Re: [linux-audio-dev] LAAGA - main components
From: Paul Davis (pbd_AT_Op.Net)
Date: Mon Apr 30 2001 - 16:26:09 EEST
>> Yup, I meant the protocol. I was playing with idea of having multiple
>> implementations of aserver. Think of ardour/aes implementing the aserver
>> protocol, so all apps using the ALSA API can output directly to
>> ardour... This is one design goal of LAAGA; make it possible to have
>> multiple implementations of the server API.
>
>This is not needed: ardour open for capture a pcm_shm that's linked to a
>pcm_lbserver (loopback server plugin) and all is done.
Yeah, all is done except for decent performance.
Ardour isn't an application anymore. Its a plugin for AES. So, first
of all, it would be AES that opens the pcm_shm. And because of the
nature of the "device", its apparent latency (based on the period
size) would never match the actual latency. The only good thing about
this solution is that its entirely the user's fault for specifying the
pcm_shm device :)
Abramo, when will you get it clear in your head that just as you are
talking about the general case, we are not? We are discussing (in
large part) a system to allow interaction between "apps" in low
latency, high-performance situations. Kai wrote:
>And of course it's clear that the LAAGA design is aimed at very specific
>use cases. One classical example used to promote ReWire is connecting
>ReBirth to Cubase. It's clear that when you have multiple files streamed
>from disk, and rebirth running at the same time, you need performance. In
>the Linux side I used Ardour and TerminatorX as examples. On the other
>hand, I think aRts is serving rather well as the KDE2.x soundserver. And
>rewriting things just for the added complexity is never a wise move...
You can *ONLY* accomplish this with in-process clients. Any system
based on sysv IPC of any kind, sockets or whatever will not perform
adequately. This has been established very clearly on LAD over the
last couple of years. You just can't do it.
the pcm_shm system is cool, as will be a loopback plugin, i'm sure,
but its a "replacement" for what aRts does now, and Stefan has already
made it clear that (at least for now) aRts cannot offer the service
that AES and LAAGA are concerned with.
i don't know if aRts or aserver makes more sense. aRts is certainly
more developed and has many features that aserver does not. but
aserver appears to me to be fundamentally inimical to an in-process
model, and as a result, can never be the basis for the kind of system
we're discussing. am i wrong about that?
--p
This archive was generated by hypermail 2b28 : Mon Apr 30 2001 - 17:03:11 EEST