Re: [LAU] Open Source Audio Interface (was Successor/replacement for RME HDSP+Multiface?)

On Mon, 1 Sep 2014, Moshe Werner wrote: 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