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

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Audio over Ethernet / Livewire
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Tue Jun 22 2004 - 11:02:40 EEST


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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Tue Jun 22 2004 - 20:03:49 EEST