Re: [linux-audio-dev] LAAGA - main components

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

Subject: Re: [linux-audio-dev] LAAGA - main components
From: Abramo Bagnara (abramo_AT_alsa-project.org)
Date: Mon Apr 30 2001 - 17:47:56 EEST


Paul Davis wrote:
>
> >> 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?

I'd answer yes...

Ok, let's try to resume: (please contradict me when I'm wrong)
- let's discard AF_INET connection between component (as not interesting
here)
- if we need for some reasons to use poll(2) or select(2) between
components of the full system, we have to use something useable with
poll/select (by example AF_LOCAL sockets).
- the full system will schedule() sometime (of course, as we are
speaking of an Unix system)

Suppose now to have a pcm_shm linked to a pcm_lbserver:
- they may be on the same process or in two different process
- they may have as a synchronization primitive poll() or if it's not
needed an user space semaphore. On SMP we can also avoid to call
sched_yield on slow path and spin entirely in user space (if we are anal
about context switch).

The thing that worries me more on all these discussion on LAD is that
you seem to focus on details, instead of design guide lines.

As an example, I remember well that you (Paul) in past has "bet" with me
that it would be impossible to build a general purpose non-RT meter
plugin in alsa-lib without to screw RT properties of main thread.

Now in alsa-lib we have such a piggy and almost nobody as noted it and
the same lock less trick will be probably used in Linux kernel for SMP
performance metering.

What I want to say is that if the design proves to be correct the
details will be solved easy.

The thing I note is that everybody is too busy to drive his flag on some
hill without watching around. I understand very well why and I know
perfectly the related climax: many children (and hairs ;-) ago, I has
been young too.

Only I think we'd need to be more constructive.

I follow with most interest the many threads on LAD but often I'm unable
to participate, sometime it seems to me an endless brainstorming,
something that flies too high and it's often unable to land down. To
tell you the truth I also envy the looong philosophical/dreaming
messages with a perfect use of the English language, something I'd be
unable to do also in Italian ;-)))

I really hope that the design of The Thing (tm) will follow a different
path and that we'll be all together on that hill with an object of
unbeaten technical quality.

-- 
Abramo Bagnara                       mailto:abramo_AT_alsa-project.org

Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy

ALSA project http://www.alsa-project.org It sounds good!


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

This archive was generated by hypermail 2b28 : Mon Apr 30 2001 - 18:24:44 EEST