Re: [linux-audio-dev] Wrappers and LAAGA

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

Subject: Re: [linux-audio-dev] Wrappers and LAAGA
From: Kai Vehmanen (kai.vehmanen_AT_wakkanet.fi)
Date: Wed Aug 01 2001 - 00:55:33 EEST


On Mon, 30 Jul 2001, Paul Davis wrote:

> Once again, I was really waiting to see if we could get a consensus on
> the overall design before proceeding with that part.

Originally I planned (the famous last words) to work on LAAGA during the
summer, but oh well, something else came up. I've spent most of my time
working on a couple of commercial-side Linux projects, and I've barely had
time for ecasound maintenance. :( Let's see how things develop during the
next few months...

Anyway, my main concerns about current LAAGA design are twofold:

[disclaimer: I haven't had time to get familiar with technical
 details of the current LAAGA proposal... ]

1) Marketing side

This is where I start yelling "it's not simple enough!". ;) Seriously, the
big question is whether the current design is something that other Linux
audio developers will start using.

I guess it's once again time for the "who's in?" poll (...as was done with
LADSPA). Ie. have you considered about adding LAAGA support to _your_
project? If yes,
        a) when (weeks, months, after enough projects have adopted
           it), and
        b) how big task do you think it is?

If no,
        what aspects of the design cause problems to you?

Putting my ecasound glasses on, my biggest worry is combining the LAAGA
connection interface (audio ports, signal routing) to ecasound's internal
design. Originally I didn't want LAAGA clients to know anything about
connections (ie. server would handle all connections, clients would just
produce/consume x mono streams of audio). Now maybe this is no big deal, I
have to spend some time on this...

2) Technical side

Well, I'm still not sure whether the multi-process approach can perform
reliably under heavy load (scheduling of multiple timing sensitive
processes), but I must admit, the results so far have been promising.
Another thing is the inherent complexity of mixing threads, ipc, signals,
audio i/o, etc. Compared to LADSPA, there's many more little
details...

-- 
 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 : Wed Aug 01 2001 - 00:57:50 EEST