> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]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
