Subject: Re: [linux-audio-dev] LAAGA API Proposal
From: Paul Davis (pbd_AT_Op.Net)
Date: Tue Jun 12 2001 - 14:32:24 EEST
>Just to speak with code, I've (quick and dirty) hacked something
>up which is different from Pauls approach. Its in "commented
>header" style, it helps if you know GLAME, but I'll try to
>elaborate. Note that I dont explicitly show implementation details
>(f.i. if using fds or not - I'm less convinced than before that
>this would be a good idea, though I'd like to use poll/select).
there is something appealing about this model, but i still have a
major reservation about forcing clients to deal with the buffer
model. if i understand the model correctly, this means that
(a) they need to manage their own ConnectionHandles within
their processing code
(b) they need to understand the loop-until-no-more-buffers
concept when reading buffers within their processing
code (i.e. clients have to do their own port mixing, etc.)
for me, this is a significant disincentive to using an API like
this. If its possible to do without it, I don't want the internal
model of the library/engine to structure how my clients operate. hence
my preference for a model where once you get the address of the single
memory region associated with the port, its just a chunk of memory as
it would be in a very simple plugin system (e.g. LADSPA). that is, its
not that i don't think this would work (GLAME shows that it does), but
that its not ideal as an API intended to be dramatically simplify
audio i/o at the same time as providing inter-application
communication and cooperation.
>The following approach (handling Ports and Connections not symmetrically)
>simply sidesteppes the issue of on-line re-connecting (the Graph is
>always online, there is no thing like "start", all connections get
>managed by the destination, the ports by the sources).
although it seems ideal, i don't think we can sidestep graph
reconfiguration. LAAGA is a synchronous system, driven by something
like an audio interface (note the word "like"). its not like GLAME
which allows totally async operation of all components. hence, the
engine has to know how to drive the graph, which means knowing the
graph order at all times. did i get this wrong?
if you move to an async model, then this is very nice, but i don't see
how it would work for low latency/real-time demands. comments?
--p
This archive was generated by hypermail 2b28 : Tue Jun 12 2001 - 15:35:05 EEST