Subject: RE: [linux-audio-dev] LADMEA Prototype
From: Richard W.E. Furse (richard_AT_muse.demon.co.uk)
Date: Fri Aug 10 2001 - 01:57:36 EEST
Very fair point - sync is a difficult problem and I'm only 90% sure it's
solved here.
I should have mentioned this more in the earlier post - there is nothing to
stop clocks ticks from being delivered by a clock generator client (this can
be generalised out to include SMPTE and suchlike) and I've been anticipating
clocks built into the exchanges themselves (and delivered through a channel
like any other data). The fact that the API doesn't specify the mechanism
hopefully(!) doesn't prohibit it - in fact this should allow more
flexibility.
Could you give me some examples where this would be a problem? I've been
dealing with the abstract for the past two days and some examples of the
concrete would be helpful!
BTW, I appreciate that the API is significantly more complex than LADSPA -
it intends to be much more general (and there's no 'S' in the name!). It's
probably in a bit of a counter-intuitive state as I only finished it today
and need to tidy it up. It's also very open in how it should be used, which
probably makes it harder in the abstract but simpler in practice. For a
normal client, the process is:
1. Find or create the channels to work with and request the data types
required.
2. Activate (some negotiation may occur to agree sample formats etc).
3. Receive incoming packets and write outgoing packets.
4. Deactivate when wish to or when requested.
Hopefully this will be a lot more obvious when I've had time to build an
SDK. I'm a bit reluctant to put too much time into this at the moment in
case radical changes are appropriate.
Thanks,
--Richard
-----Original Message-----
From: owner-linux-audio-dev_AT_music.columbia.edu
[mailto:owner-linux-audio-dev_AT_music.columbia.edu]On Behalf Of Paul Davis
Sent: 09 August 2001 23:16
To: linux-audio-dev_AT_music.columbia.edu
Subject: Re: [linux-audio-dev] LADMEA Prototype
[...]
Summarised, thats because to work in the way expected by users (and
quite reasonably so IMHO), the "network" needs to be driven by a
uniform, overarching "clock" that ticks universally for every node. A
node may choose to do nothing on a tick, but it must be "called" and
return synchronously at each tick. Any system based on a model like
"sendToExchange" and "sendToClient" will, I think, be susceptible to
the same kind of network halting problems that GLAME can encounter,
though within GLAME, this is arguably a feature rather than a problem.
In LADMEA, the problem is slightly the reverse of the one in GLAME,
since LADMEA appears to use a push-to-whoever model, rather
than a pull-to-me model. But the same basic issue still applies. I
think.
Did I misunderstand something?
--p (back on monday, august 13th)
This archive was generated by hypermail 2b28 : Fri Aug 10 2001 - 01:59:02 EEST