On Mon, 1 Sep 2014, Moshe Werner wrote:
I like your Idea! That would be the ideal modular platform.
But if we're going the ethernet route why not Ravenna? It's open
Ravenna has not been used by a number of people/manufacturers because the
latency is too high. It is less than 10ms, compare this with madi, or
dante. The idea is to at least match what audio users can get from USB
(5-6 ms round trip at 48k) but hopefully come closer to internal or FW.
Ravenna is built for just throwing against a building's LAN and includes
the needed overhead and latency to do so. We want better.
MADI or ADAT add very little in the transport phase of their delivery, we
want the same because we still have codec time and DSP time. It is not
good enough to spend time developing something that is good enough for
recording, but it also needs to be good enough for live performance and
other exotic (to us now) needs.
So what I am suggesting is to steal the ethernet IF and use it in much the
same way as MADI, but effectively take the unused channels and send
network traffic with it. MADI is based on 100meg network, but it is easy
to get 1000Meg or better any more.
So my idea is that:
- in time with the word clock a stream of data is sent over the ethernet.
- it is less than the length of one word clock pulse
- The data includes:
x channels of audio formatted as consecutive AES3 (like MADI)
An end of audio tag
a data tag that tells how much data is within the frame
regular data packets perhaps encapsulated in some form.
- both ends look to the OS like both an audio device and an ethernet port
- One end is responsible for breaking network data packets apart
- the other end puts them back together.
Problems:
- ethernet hardware, it is all different.
- some hardware includes it's own CPU/DSP to off load the host.
- kernel hacking is beyond my comfort zone
- linux ethernet is really stable, mess with it?
This may mean moving the sw up a level, but still doing the same thing.
The only way to get good solid low latency over ethernet is to take over
network data transport or have exclusive use of the ethernet port in
question.
Taking over the NIC is to be prefered (IMO) because it would allow such an
audio interface to be used with any computer even a laptop with only one
ethernet port. (wlan may not be usable)
exclusive use of the nic will allow more channels total and be easier to
do :) In fact this may be a better first attempt or development step...
but only if the goal above is kept in mind. that is network data within
the the stream should not be precluded by this step.
Comments on low latency:
low latency means different things to different people, it ranges from
sub-ms to about 50ms.
Machine control is all sub-ms (by quite a lot)
Madi can be sub-ms RT (return trip)
asterisk expects to talk to it's PCI(e) cards for audio info once per ms
FOH snake use seems to require ~3ms RT
Recording with some SW monitoring seems to work up to about 10ms RT as
does live swsynth/effects use. (some people will dissagree)
Recording with analog monitoring except for already recorded tracks can
work at 20ms or higher. There is no RT in this case.
skype uses 20-30ms latency.
A radio console (like idjc for example) seems to work ok at 10-20ms even
with skype as an online phone tool.
mp3 streaming is not low latency being 200 or more ms one way.
--
Len Ovens
www.ovenwerks.net
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
