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: Paul Davis (pbd_AT_Op.Net)
Date: Sat Apr 28 2001 - 02:34:21 EEST


>Converting an existing audio server into a LAAGA server should be quite
>easy in most cases. On the client side, things are much more difficult.
>For instance, let's take a simple single-threaded audio file player as an
>example. The inner loop is something like:
>
>--cut--
>while(eof() != true):
> read_from_file() // can block
> apply_eq()
> write_to_soundcard() // can block
>--cut--

An excellent concern to start with, since this is indeed a fairly
common pattern in existing Linux audio apps.

>But how to convert the above into a LAAGA client; basicly we have two
>approaches:
>
>1) Implement the above as a callback function
>
>--cut--
>process():
> read_from_file() // can block
> apply_eq()
> server->write_to_laaga_channel()
>--cut--

i prefer this model over your second one, but i understand the problem
with read_from_file(). one possibility might be to identify the things
that might reasonably be expected to do in process(), and provide
non-blocking methods of doing all of them. however, given that
read_from_file(), which may look simple, really is not simple at all
for some applications (e.g. ardour), i'm not sure that this is a
promising approach.

>Now I think to the two big questions are:
>
>- what is allowed in process()
>- who performs the process-to-process communication

let me add:

- *is* there any process-to-process communication?

>Now it's not clear what we should aim at? Maybe we should limit LAAGA to
>only support 1.3. Ie. client application provides a set of callback
>functions (audio server context), and one function that is forked() as the
>main() of a new process. At the moment, this approach sounds rather good
>to me. Comments?

that would work. however, it does fail to address the question of how
the other process (the "worker/gui process") communicates with the
code and data being used within the audio thread.

this is essentially the dilemma faced by the LADSPA GUI question.

much careful thought about all these issues is needed. thanks for
getting the ball rolling.

--p


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

This archive was generated by hypermail 2b28 : Sat Apr 28 2001 - 03:17:21 EEST