Subject: RE: [linux-audio-dev] LADMEA Prototype
From: Richard W.E. Furse (richard_AT_muse.demon.co.uk)
Date: Thu Aug 16 2001 - 22:54:01 EEST
You will have realtime/clock sync problems for instance when your clock is
on a different box to a real audio input or output. What happens if the
crystal on the audio card isn't in sync with the clock. Or one audio card
with another? This is a common problem.
Assuming this problem is resolved somehow, there's still no guarantee of
relative arrival times across a network (unless you want to use slow
centralised locking techniques, which will fail for latent networks). You're
going to have to implement latency requirements on inputs to judge when a
client has failed/is late. If you want to stream things other than PCM audio
you're going to need to be able to describe these data types and push them
across a network to a potentially different piece/version of
software/hardware. If you want to go *near* ATM you'll have to find some way
to describe your bandwidth requirements, bearing in mind that a well-written
exchange needn't understand the underlying data type. All this is the "new
layer" I was suggesting you'd need - before you know it you'll rewrite
LADMEA :-) Of course, you're right that sending data over a bridge is
non-trivial. This is why LADMEA doesn't have an 'S' in it!
Incidentally, as I think you suspect, it *is* possible to drop or add
samples to deal with sync problems. This is a well-known issue that hardware
digital mixers in the real world have to face. This is partly why they are
expensive - but the technology has been around for quite a while and we
really ought to be able to mirror it in our software-synthesis world. A
mixture of techniques are used, from dropping or inserting samples (bad) to
resynthesis of a block of audio with a length change (good but costly).
[Aside in case I didn't mention it recently: LADMEA allows you to use clocks
to drive software to keep it in sync that way. The clock tick is a data type
like any other (probably with a rather tight latency requirement!).]
As I've said before, the zero-copy issue I'm flexible on, I'd just prefer to
put it off until more fundamental issues are resolved. It isn't conceptually
hard but it is fiddly.
--Richard
-----Original Message-----
From: owner-linux-audio-dev_AT_music.columbia.edu
[mailto:owner-linux-audio-dev_AT_music.columbia.edu]On Behalf Of Steve
Harris
Sent: 16 August 2001 12:37
To: linux-audio-dev_AT_music.columbia.edu
Subject: Re: [linux-audio-dev] LADMEA Prototype
On Wed, Aug 15, 2001 at 11:14:09PM +0100, Richard W.E. Furse wrote:
> This approach can be mediated by the exchange - a clever one can observe
> that two network machines are drifting out of sync and add or delete
samples
> to fix this. As far as I'm aware, LAAGA would need a whole new layer to
deal
> with this. I'm attempting both steps in one.
I don't think so. I was actually planning to implement one of these if
LAAGA takes off, I would have made a bridge driver that ran on both
machines and piped data between them.
The bridge would be synchronous (is that the right term, driven by the
arrival of data anyway), so drifting out of sync wouldn't be a possibllity.
I'm not coinvinced that its possible to add or delete samples to patch up
sync problems without having audible effects or too much overhead.
Obviously sending data through a bridge is not as versatile, but I don't
think its something that should be done lightly anyway. Even over ATM.
> context - LADMEA is intended primarily for inter-app communication, so
> zero-copy isn't nearly such a priority as in LADSPA IMHO.
I suspect that you're underestimating the amount of CPU that will be taken
up with the overhead of running the system, but we will see.
- Steve
This archive was generated by hypermail 2b28 : Thu Aug 16 2001 - 22:54:33 EEST