Subject: Re: [linux-audio-dev] Audio over Ethernet / Livewire
From: Michael Ost (most_AT_museresearch.com)
Date: Tue Jun 22 2004 - 19:30:19 EEST
On Mon, 2004-06-21 at 23:20, Benno Senoner wrote:
> Since we want sample accurate midi triggering (which traditional MIDI
> over serial does not provide) we could do the following:
> a MIDI command is usally not longer than 3 bytes (let's forget abut
> sysex etc for now).
Perhaps sysex calls for a second midi-only packet type. Sysex could be
encoded as a start packet and some number of continuation packets. A
midi only packet could also let a driver send more than the 344 midi
messages at a time you spec'd out, if it needs to.
> we could divide 400 bytes into 100 midi events consisting in:
> 1 byte timestamp relative to the audio fragment (0-127) , this would
> limit the fragmentsize to max 256 frames
> 3 byte midi payload
A couple of thoughts:
Midi seems very compressable. You'd get a lot of 0x90s and 0x80s, for
instance. Is that worth pursuing?
Is some sort of 'sequence' number needed to make sure packets arrived in
the right order? Or perhaps UDP manages that...?
> In the case of serial MIDI you achieve a maximum about (3byte MIDI
> events) 1000 events/sec.
>
> In our case we send about 344 packets/sec which multiplied with 100 midi
> events gives us
> 34400 events/sec which are SAMPLE ACCURATE !
> basically it would be like having the equivalent 34 midi interfaces.
Do you want to take a stab at a comparison with USB based MIDI?
> Such a (bidirectional) audio/midi stream would consume about
> 500KByte/sec , which means a 100Mbit LAN could run 10-15
> of those at the same time without loosing data.
>
> basically it would work as follows:
>
> client PC (has an audio card) <----> jack server PC (runs jackd and jack
> clients like samplers, softsynths, HDR apps etc, no audio card).
>
> the client PC would run a jack network client which does the client PC
> <---> server PC communication
>
> the server PC has a special (not implemented yet) jackd input/output
> driver which recieves/sends the audio data to the network,
> for the rest the jack clients residing on the server PC don't know
> anything about the network, to them it looks like a standard jack server.
>
> The "clock" to the jackd residing on server PC is given by the client PC.
A Windows/Mac/ASIO driver-like interface would extend the usefulness in
lots of studios.
We're (Muse) also very interested in this sort of technology. We'd most
likely want to run VNC alongside a protocol like this. Do you think that
would saturate a 100 base T network?
Muse may be able to provide some programming resources if things work
out for us and the proposal looks good.
- mo
This archive was generated by hypermail 2b28 : Tue Jun 22 2004 - 19:22:40 EEST