Subject: RE: [linux-audio-dev] LADMEA revisited (was: LAAGA and supporting programs)
From: Richard W.E. Furse (richard_AT_muse.demon.co.uk)
Date: Thu Oct 04 2001 - 23:28:39 EEST
> -----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: 02 October 2001 23:12
[...]
> >Yep, but SHM isn't the only answer. Sockets provide a particularly useful
> >implementation.
>
> Sockets still force a data copy and they are bandwidth limited as well
> AFAIK. They also don't offer RT characteristics. Try to write a lot
> of data to a socket, and the kernel will do a bunch of
> non-deterministic memory allocation to accomodate you.
Yep, but sockets allow audio and other data to be streamed between machines,
very useful live in a studio. The point is that different exchanges are
suitable for different contexts. If Alice write a whole load of drivers for
JACK that use SHM to stream float audio, MP3 audio, MIDI, video etc etc
between clients, what happens when Bob want to pipe this data to another PC
in his studio. Does Bob really have to write separate new drivers to stream
float audio and MP3 audio and MIDI and video etc etc all over again but
using sockets this time?
Say this has happened, and Clive has just written a couple of new clients
that make funny noises using a new format (say 10kb DWT packets every 0.1s).
To use SHM, Clive has to delve into Alice's code and write a new driver
using SHM (or persuade Alice to do it - or start again from scratch - and
you know how much programmers like to do that). To use streams, Clive has to
delve into Bob's code (etc).
This seems to me to be a lot of wasted effort. Given a reasonable
description of the data type the exchange can automate this. In a LADMEA
world, there would probably be two exchanges here: a SHM based one and a
socket based one. Adding a new data type merely requires Clive to provide a
description of his data. And Alice and Bob never need to get their heads
around quite what an evil thing the DWT can be...
[...]
> if its process() callback takes too long, the client is removed from
> the graph. the graph will fail to meets its deadline on that
> particular execution cycle, but then it return to normal.
How are deadlines defined? Presumably these rather depend on the entities
downstream. A low-latency audio stream might by definition have a very early
deadline, however MIDI may be a different matter (a millisecond or two here
or there doesn't really matter) - and I seem to remember JACK is intending
to block MIDI which will unnecessarily *induce* latency of anything up to
the block length. But that's mostly a detail of implementation rather than
design philosophy.
> >> 7. Consider a case where none of the clients in a graph require
> >>live operation, e.g. a MIDI player is playing a 10min piece where
[...]
>
> just clock the server from a driver that isn't wired to an audio
> interface, but instead does file i/o. it can call process() as rapidly
> as it can pass of the data to some file i/o method (either write(2) or
> a buffer with a thread on the other side of it).
How does Dave write this? He wants to able stream video and MP3. And what if
he wants to be able to run some of his clients on different machines. And
actually he think's Clive's DWT thing is quite cool and would like to stream
this across his network (but has no idea what a wavelet is).
[...]
> I don't see that
> JACK has any problems handling any of these, other than the ones that
> arise from the interval size potentially being too large for some of
> the data types to be delivered "on time" (e.g. MIDI driven by audio).
This is why understanding bandwidth requirements is important. Modern
techniques can give bandwidth/latency/jitter guarantees, but these are only
useful if one knows ones requirements. Similarly, a live RT system can
refuse to glitch when it knows a change to its bandwidth requirement isn't
possible.
>
> --p
--Richard
This archive was generated by hypermail 2b28 : Thu Oct 04 2001 - 23:29:41 EEST