[linux-audio-dev] Audio over Ethernet / Livewire

[Benno Senoner]

Michael Ost wrote:

> 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. 
>  
>
this could be an option.

>
>A couple of thoughts:
>
>Midi seems very compressable. You'd get a lot of 0x90s and 0x80s, for
>instance. Is that worth pursuing?
>  
>
of course, mine was only an example that even uncompressed MIDI would 
provide a really high
midi events/second rate.

>Is some sort of 'sequence' number needed to make sure packets arrived in
>the right order? Or perhaps UDP manages that...?
>  
>
UDP does not provide a guarantee that packets arrive in order but I 
think if the network is not saturated
(which is MANDATORY otherwise we get choppy audio) and we use a simple 
windowing approach
where we enqueue 1-2 more packets in advance (as in my proposal) the 
probability of getting a packet
relative to 2-3 process() cycles ago is pratically zero.
Of course we need to write the benchmarks that prove this (under high 
network load (but not an overloaded network)).
If we do such simulation via benchmark and run it 1-2 days without 
getting out of order packets or losses we can
claim it works well for professional audio.

>>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? 
>  
>
USB MIDI is certainly faster than serial MIDI (but I don't know how much 
faster), the problem of USB is
AFAIK that the bus is polled each msec or so this means that raw midi I/O
(eg a midi keyboard connected to PC via USB midi interface) is affected 
from a bit of jitter , which is not present
in serial midi (since it has a constant clock).
Probably not a big issue. But USB MIDI interfaces do not provide 
timestamped midi events
(there are some exceptions like the ones from Emagic).

>
>>
>>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. 
>  
>
yes it's just a matter of writing the software, any kind of audio 
interface API, plugin interface like VST/AU can be used
as a client for those jack network clients.

>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?
>  
>
AFAIK you can limit the datarate of VNC traffic and as Steve said if you 
enable QoS things should go well.
(Linux provides that and  it's mostly only required on the transmission 
side (the linux box, muse is linux too :) ) since most traffic VNC 
generates is from the server (muse box) to the client (a windows PC).

>Muse may be able to provide some programming resources if things work
>out for us and the proposal looks good.
>  
>

cool.
As said the ideal would be if there was a community effort to push such 
a solution forward, just like the
jack system, LADSPA etc was created.

> I'l note that rolling yet another MIDI over UDP/TCP protocol is really
> stupid, there are 3 that I know of: IEEE-whatever, RTP-MIDI and OSC.

Steve, I'm not a big fan of reinventing the wheel,
the problem is here we are talking about combined audio and midi into 
single packets (for performance reasons),
high datarates (much higher than 30-64kbit VOIP apps) etc.
There is no IEEE RFC for now that covers our problem offering an optimal 
solution.
As said let's keep discussing, trying out proof of concept code, fail , 
iterate again and see what comes out.
as usual :)

cheers,
Benno
http://www.linuxsampler.org