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: Kai Vehmanen (kaiv_AT_wakkanet.fi)
Date: Mon Apr 30 2001 - 00:03:15 EEST


On Fri, 27 Apr 2001, Paul Davis wrote:

>>--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.

Hmm, it might be better to first concentrate on the well-behaving LAAGA
clients, ie. those that already have solved the read_from_file() issue. So
LAAGA clients would provide:
        - server callbacks
        - one function for spawning the GUI-process

So here, it's client's responsibility to implement the IPC, and take care
of blocking system calls in process(). If (or when :)) we get this
working, then the next problem is converting existing audio apps (... and
how to make connections between running apps...).

In this second phase we probably need a stub LAAGA client plugin, and a
set of client-side library functions for communicating with the server
process. This means that there will be at least three distinct APIs:
        1) LAAGA server-side API
        2) LAAGA direct client API
        3) LAAGA stub client API

With (3), it should be quite easy to provide an ALSA/OSS style API for the
client apps.

>>Now I think to the two big questions are:
>>- who performs the process-to-process communication
> let me add:
> - *is* there any process-to-process communication?

Now using the above numbering, LAAGA APIs (1) and (2) don't require
any kind of IPC. But with (3), we need IPC. Otherwise connecting apps
using different GUI-toolkits will not be possible.

>>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.

Ok, I guess what I describe above is the (1)+(2) LAAGA API
combination. To handle the IPC, we have API (3).

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

Indeed. I just hope that we can get other to join in. For instance, Stefan
and Abramo, how these plans seem like from your perspective? Do think
we're recreating aRts or aserver, or are we onto something. Can yoy
picture aRts/aserver as an implementation of one of the above? And others,
too, how does LAAGA seem from your project's perspective? Where its place
in the overall picture?

-- 
 http://www.eca.cx
 Audio software for Linux!


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

This archive was generated by hypermail 2b28 : Sun Apr 29 2001 - 23:59:30 EEST