Hello. I'm currently working on a project consisting on transmitting and receiving two channels of audio over the TCP/IP protocol. This is also known as a "digital snake" in the audio industry. Anyway... I currently have the ADC and the Ethernet part (almost) ready to prototype, but I will appreciate if you could take a look at it and give me your opinion.
. As an ADC I'm using a TI PCM1807 with a PLL1705 to generate the sampling clock. It is a 2 channel 96kHz 24-bit ADC. As the ethernet controller, I'm planning to use a Microchip ENC28J60 because it seemd to be "easy" to use. The FPGA board is a Papilio One with a Spartan 3E 250K. I decided to go for an FPGA instead of a microcontroller because if I ever wanted to send/receive more channels, I could benefit from its massive parallelism. I'm planning on doing all the TCP/IP packing and unpacking inside the FPGA.
Thanks!!
You sure you don't want to go for UDP/RTP? TCP/IP on FPGA is too difficult to do. I'd recommend to go for 10/100 Mbps PHY, implement ethernet MAC on the FPGA and do the audio transmission using UDP as it is commonly done in broadcast tv environment.
You sure you don't want to go for UDP/RTP? TCP/IP on FPGA is too difficult to do. I'd recommend to go for 10/100 Mbps PHY, implement ethernet MAC on the FPGA and do the audio transmission using UDP as it is commonly done in broadcast tv environment.
Yes, I actually said TCP/IP referring to a network protocol, but since this is real time data streamming and low latency is waay more important than "reliable data transfer" (not that that is not important), I was planning on using UDP instead of TCP, but thanks for the advice!!
I remain dubious about sending high channel count audio over the "regular venue" switched network. A dedicated network (or simply end-to-end cable run) seem far more reliable.
I have thought that an arrangement with 8 (or 16 or 24) of a THAT 5173 controlled mic preamp like the Innersonix Lucidity and running over an ordinary Cat5 cable would be a killer product.
THAT 5173 Digitally Programmable Gain Controller IC
http://www.thatcorp.com/5173_Digital_Preamplifier_Controller_ICs.shtmlInnersonix Lucidity Digitally-controlled Mic Preamp
http://diy.innersonix.com/shop/lucidity-preamp
I remain dubious about sending high channel count audio over the "regular venue" switched network. A dedicated network (or simply end-to-end cable run) seem far more reliable.
I agree with you. I'm doing this with the idea that people will use it with direct connection or maybe with one dedicated high end switch.
I have thought that an arrangement with 8 (or 16 or 24) of a THAT 5173 controlled mic preamp like the Innersonix Lucidity and running over an ordinary Cat5 cable would be a killer product.
THAT 5173 Digitally Programmable Gain Controller IC http://www.thatcorp.com/5173_Digital_Preamplifier_Controller_ICs.shtml
Innersonix Lucidity Digitally-controlled Mic Preamp http://diy.innersonix.com/shop/lucidity-preamp
That is a really cool idea! Some nice features like a good preamp may make this much more than just an audio snake. Thanks!
I don't know how much detailed information they release, but look up Audinate Dante.
In the pro AV world, it's one of the more popular ways of transferring live audio over networks without needing special switches (unlike another big contender, AVB).
Virtually all of those "pro" digital audio protocols (including Dante) require hefty payment and/or joining the "club" in order to access the specifications. The kind of payments required put them WAY out of the range of hobby activities.
I don't know how much detailed information they release, but look up Audinate Dante.
In the pro AV world, it's one of the more popular ways of transferring live audio over networks without needing special switches (unlike another big contender, AVB).
Actually Dante was the thing that motivated me to do this. My ultimate goal (which is a quite ambitious one
) is to make a cheaper and open source alternative for audio networking
.
I've recently been looking at the range of audio-over-IP gear from Barix. How well it works over a mixed network remains to be seen.
I've recently been looking at the range of audio-over-IP gear from Barix. How well it works over a mixed network remains to be seen.
It does look interesting. They seem to have a lot of features!
Cheapest implementation of Audio over IP has been Cirrus logics Cobranet chips:
http://www.digikey.com/product-detail/en/CS181012-CQZR/CS181012-CQZR-ND/2036609
There is a lille bit of pricing elasticity going up to 16 channels or down to 2 channels. You'll be hard pressed to beat that solution with an FPGA, but it like all the other products locks you in to a specific protocol/ecosystem.
Well... I wasn't expecting that XD It does seem to be a killer chip and CobraNet looks really cool. Thanks for the info!
I would not go the pure hardware route, myself. software gives so much more flexibility.
I'm a networking guy, by trade, and switching/routing is something I do for my day job.
QOS would be one way to prioritize the traffic. carving out tunnels or 'flows' would be another.
I like the idea of having multiple channels open, monitoring them and actively picking the fastest one (or few) and bonding them together. with software, you can do that. with hardware, not so easy.
as long as you can tolerate buffering a bit, software is the way to go. if you can't tolerate latency or buffering, you have no choice but to throw lots of bandwidth or dedicated lines at this.
For Ethernet I'd recommend to implement CoS to allow frame prioritisation by the switches. For the IP layer DiffServ would be nice. And you don't need "high end" switches. Today, even dumb and unmanagable desktop switches support CoS.
also, what is the distance? could this be all-LAN or is WAN needed? can radio be used?
I would not go the pure hardware route, myself. software gives so much more flexibility.
Trying to maintain time(code) synchronisation between the points of the network is much harder than you imagine, audio dropouts/inserts/slewing is very obtrusive so the codec clocks all need to be synchronised. Dedicated hardware is used to provide the agile clocks which aren't present in other audio designs even if the feedback is all done in software.
and that's why I said 'buffering'. with buffering and network time that you can trust, it can be done in software. pretty sure..
but if buffering is not tolerated in the requirements, then you can't take this easy way out.
You can tolerate that kind of latency if you are only audio recording, or radio broadcasting, etc. But if you need anything remotely resembling "real-time" (like live sound reinforcement) or A/V sync (like video production) that kind of latency and unpredictability is a show-stopper.
We're talking about audio here and latency's in the range of ms ... you don't need hardware for that.
On a 50 MIPS microcontroller you can run 5000 instructions before you use even 10% of the lowest latency budget cobranet has ...
and that's why I said 'buffering'. with buffering and network time that you can trust, it can be done in software. pretty sure..
but if buffering is not tolerated in the requirements, then you can't take this easy way out.
The clocks of the ADC and DAC wont be synchronised, so how do you make up for drift/accuracy in their oscillators as you eat through the buffer? Glitching by dropping or adding dummy samples wont be pleasant.
We're talking about audio here and latency's in the range of ms ... you don't need hardware for that.
You do need hardware, but feel free to show the world how to synchronise digital media on remote oscillators running with arbitrary frequency offsets. Its a fundamental issue of digital broadcast/transmission systems.
Piecewise Polynomial interpolation is cheap, just need to come up with some buzzwords in case you have to sell it to an audiofreak.
Audio isn't that fast that you'd need an fpga do work with it.
Find some microcontrollers with I2S and MAC (ethernet) and create your very own gigabit* network connection.
Unless there is need for compression...
*Or Fast Ethernet