How about a dual-protocol network-attached audio device? For
professional recording it uses a custom time-division multiplex protocol
over Ethernet, providing absolute timing precision and dead-constant
microsecond latency. For casual use with a standard computer, it uses
TCP/IP, and resorts to time stamps to match up track timing from different
boxes during playback and mixdown from the hard disk.
Network capacity would be lower with TCP/IP, and the subnet would
still have to be dedicated to audio to guarantee delivery of every packet.
One possible board product for a computer would be an Ethernet card
that could handle the custom low-level protocol without dropping frames.
That's an all-digital product, and it would fall within Traversal's skill
set.
I don't think dual-protocal will be needed. If you just use a cross-over cable you will be getting near ideal transfer. We actually don't need the overhead of TCP in the system either. If we implement it so it will work with IPv6 we have inherent QOS services available. Then we can use UDP to move the actual data. If a packet gets mangled or goes missing we can just skip it. We don't want the in order nature of TCP to hold up the data. If it just gets played out of a queue and the data isn't there it can just do some sort of aliasing using the previous and next available sample. Also IPv6 is going to let us do multicast magic if we need multiple ADC boxes or CPUs working together on the same data.
A useful paper on ethernet latency: http://www.ieee802.org/1/files/public/docs2006/avb-azarov-ApproachToLatencyBoundEthernet-060130.pdf
From what I have read it looks like 20ms is the target number for decent latency, as well I believe that this is what steinberg tools aim for. The biggest enemy for us will be the latency of the operating system. Linux has not exactly had a stellar record in that area. Our target should be an assumption of a decent 1Gb nic, running a non-RT linux, and a decent switch. Link delay can be up to 1msec, switch delay can be all over the place so I will figure 2msec there, linux isn't so hot at low latency so maybe 5msec there. So we end up with 18 msec with no actual processing going on. Not looking to good.
The problem is if we do all the audio processing on the CPU we end up having double the latency. It takes 11msec each way. This means that anything going on that needs to be real time needs to be processed in the ADC box. A method of beating this might be to have a processor that can do everything in realtime. At a minimum it should be able to a reduced sample rate preview of all effects. Then when the ADC data traverses the network to the CPU it can do a full version of the effects and record them to HD or resend them for broadcast over PA at a higher latency.
I think what this is going to end up looking like is more a virtual audio device with its interface forwarded over ethernet. Then we can have a control program that determines where that data ends up. You could have 1 ADC box multicasting to 2 PCs. Each PC could be processing in tandem and allowing for more complex effects. You could bond specific effects and channels to individual machines. Also you could have 2 or more machines processing one efffect by interlieving the output samples between them. If there are 2 machines, each machine would process and output every other sample. There might be a few latency issues with it, and the ADC box would need to be able to reconstruct the channel.
So things look like they will work. Just has some latency and fudge factor issues to workout. True real-time might be a problem, but I think if its used in a pro/semi-pro setting they are workable.
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
