Subject: Re: [linux-audio-dev] LADMEA revisited (was: LAAGA and supporting programs)
From: Paul Davis (pbd_AT_Op.Net)
Date: Fri Oct 05 2001 - 01:55:06 EEST
>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.
Agreed. But JACK connects clients on the same host. There is nothing
to stop one of those clients having its own connection(s) to on other
host(s). JACK won't know (or care) about that. It only cares that its
clients meet their deadlines. What they are doing with the data
outside of the callbacks is quite beside the point as far as JACK is
concerned.
> 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,
1) Let be clear. Its the JACK client-side library that (currently) uses
SHM. No driver includes code for this (unless it does so explicitly
for some reason), and no client does either (unless it does so
explicitly for some reason). Clients are utterly unaware of the method
used to move data between them. Its not impossible that some other
implementation of JACK might not use SHM: clients would have no clue
that this was the case. All they know is that a port provides a memory
location where they can read and write using normal memory access
techniques.
2) Reread that blob of text again. Why would Alice do this? drivers
don't do that. Drivers simply power the JACK server, making sure
it invokes its processing network periodically. They also typically
connect a set of ports with a h/w resource, but regular clients can
do that too. What you described is sort of what JACK itself does -
Alice doesn't have to write it.
> 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?
Absolutely not. There would be a client that streamed data from its
input ports across the network to a process on one or more other
hosts. I already wrote such a client as a test; it basically worked,
but as the McGill guys and everybody else who has tried
full-resolution network audio, there are tricky buffering issues that
weren't worth my while resolving. It was just a toy to see if the
basic idea would work.
>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
Again, clients have no clue about the transport mechanism. Clive's DWT
client would just be reading and writing to memory, exactly like every
other client.
>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).
Nope. He just fires up his DWT client, and a network streaming client,
connects the output(s) of the DWT client to the input(s) of the
network client, and everything works like a charm (assuming that the
clients are all well-behaved.
Except, of course, the network client has to be willing to handle DWT
data. You can't connect a DWT output port to a PCM audio input
port. If you allow this kind of thing to happen without any action by
the user, you open up all kinds of ratholes. If there is no DWT-aware
network client, Clive will have to write one, but he's in luck,
because its going to be extremely easy to do. 90% of his code will be
generic network streaming code, and only 10% or even much less than
that will have anything to do with JACK. When the DWT type was
defined, it has to come with a descriptor that specifies how to handle
it. Clive will just use that descriptor when declaring the input ports
on his DWT-aware streamer and in its process() callback.
See, isn't it beautiful ?
>How are deadlines defined?
The main engine thread in the server is given a "tick" signal that
comes with a temporal interval as an "argument". If any stage of the
processing tree takes longer to execute, the client is deemed to
have timedout. If the entire tree takes longer to execute, then the
entire tree is deemed to have timedout. No other knowledge is
required.
It occurs to me that in the "offline" case, this needs a little work,
since there really is no such concept as a "timeout", and there is no
way to know for sure what the "time" associated with "N audio frames"
might be, for example. But I think this can be handled easily by a
very minor modification to the JACK driver API.
>> 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.
But how can you know that unless every node in the processing tree is
hard-RT (or perhaps we could call that "hard-DSP") (i.e. can guarantee
a fixed cycles-to-interval-processed ratio), and can enumerate that
ratio. This seems almost impossibly hard to provide on a general
purpose CPU with branch prediction, pipelines and so forth. If I
insert a cycle-heavy plugin into a processing tree, I will kill the
tree. Unless the plugin can tell me that its a heavy cycle eater, or
perhaps is a heavy cycle eater only when the signal levels get low, if
its running on an Intel CPU, because it doesn't denormalize, then I
can't know that it will have this effect. Ergo, I can't understand
that it should not become part of the tree.
--p
This archive was generated by hypermail 2b28 : Fri Oct 05 2001 - 01:51:32 EEST