If the debate is about raw data over USB vs. raw data over ethernet, the former may not be that much harder to implement than the latter: use a FTDI chip for the USB interfacing, they provide a free to use driver along with a clean library, and it's well thought-out and hassle-free. You'll probably get lower latencies, on average, than with regular ethernet via a socket (UDP or TCP). Of course, you can write your own optimized ethernet protocol, but then that would be a much harder work in my opinion.
As for isolation, you may isolate at the I2S level instead of at the USB level - or between the USB controller and the microcontroller if you use a dedicated chip like FTDI's ones.
The only problem I see with USB is that, whereas using full-speed (12 Mbps) is rather straightforward (there are several "almost ready to use" solutions), if you need more throughput (like high-speed USB 2.0), there is virtually no simple solution apart from the Cypress microcontrollers (FX2), but you would have to write the USB driver yourself (not trivial if you want good throughput), and you would most likely need an additional microcontroller for I2S output, or an FPGA. A pain, but doable.
Note that if you want more than 10 Mbps ethernet, you're in for a rough ride as well...
I have not decided on an interface myself yet. Almost looks like we would need to devise a brand new one...
At one point, I had thought about some kind of isolated RS-485, but that would probably mean a dedicated PCI card, a special driver on the computer... a lot of work.
I am now thinking about not using a computer at all. Interfacing between modules could indeed be some kind of RS-485 or LVDS (cheap, fast and reliable).
As for isolation, you may isolate at the I2S level instead of at the USB level - or between the USB controller and the microcontroller if you use a dedicated chip like FTDI's ones.
The only problem I see with USB is that, whereas using full-speed (12 Mbps) is rather straightforward (there are several "almost ready to use" solutions), if you need more throughput (like high-speed USB 2.0), there is virtually no simple solution apart from the Cypress microcontrollers (FX2), but you would have to write the USB driver yourself (not trivial if you want good throughput), and you would most likely need an additional microcontroller for I2S output, or an FPGA. A pain, but doable.
Note that if you want more than 10 Mbps ethernet, you're in for a rough ride as well...
I have not decided on an interface myself yet. Almost looks like we would need to devise a brand new one...
At one point, I had thought about some kind of isolated RS-485, but that would probably mean a dedicated PCI card, a special driver on the computer... a lot of work.
I am now thinking about not using a computer at all. Interfacing between modules could indeed be some kind of RS-485 or LVDS (cheap, fast and reliable).
There was this wonderful thread back in 2006 about multichannel LVDS
http://www.diyaudio.com/forums/showthread.php?s=&threadid=22741&highlight=
It is more a hardware approach to what is being attempted here with perhaps less flexibility but very worthy none the less.
http://www.diyaudio.com/forums/showthread.php?s=&threadid=22741&highlight=
It is more a hardware approach to what is being attempted here with perhaps less flexibility but very worthy none the less.
The “only” coding difference between USB and Ethernet with respect to audio is the layer that actually transmits the bits. Once you have that layer, the rest (layers above) is the same. For Ethernet/IP you often have this layer (consisting of a number of layers on its own) implemented when you purchase the hardware. For USB you often have to implement it. This is why people perceive USB more difficult to code than Ethernet. Needing to implement the whole Ethernet/IP/UDP stack you would say that USB is simpler, but then you usually don’t have to.
I don’t know whether my USB DAC uses galvanic isolation or not. But I cannot hear any difference in silence at full volume level whether the box is physically connected to a PC or not. If there were any noise coming from PC when not playing anything then I would hear it. It is also difficult to see why this noise would appear only when actually playing something (and therefore be masked by the music). Then again, who knows, maybe there are PCs and PCs as well as DACs and DACs.
I don’t know whether my USB DAC uses galvanic isolation or not. But I cannot hear any difference in silence at full volume level whether the box is physically connected to a PC or not. If there were any noise coming from PC when not playing anything then I would hear it. It is also difficult to see why this noise would appear only when actually playing something (and therefore be masked by the music). Then again, who knows, maybe there are PCs and PCs as well as DACs and DACs.
Yeah, modern computers have this problem : they are super powerful, but there is no easily accessible data I/O for tweakers. Serial and parallel ports are obsolete (and always sucked) ; this leaves USB, FireWire and Ethernet basically. Using a mobo slot is dangerous : Ethernet will outlive PCI, PCI-X, and the next few generations, because it's a lot easier to change a mobo and boards than to rewire a building. I would bet USB will still be there in 20 years, too.
Yes, you see what I mean ? I went through all this, I also considered a lot of USB chips, but high-speed USB is not very DIY friendly. Also, a friend of mine who professionally writes USB2 drivers told me to stay the hell away from it.
Eh ? I have 100 Mbps running on the Suzaku, no problem at all, and I'm quite confident I can do the same with the NGW100 ; the choice I'm facing now is, can I do it with Linux (I'd like to keep Linux) or will I have to go stand-alone ?
The reason I'm ditching the Suzaku isn't that it can't handle the throughput, it's the damn 48 KB of BRAM ; I can't put an extra line of code and I still need more features.
A lot of work, would it get finished ? I prefer OEM modules...
I thought FPGAs were hard, then tried ; it took me av evening to write a multichannel configurable parallel to I2S encoder...
AudioWizard said:
Yes, you see what I mean ? I went through all this, I also considered a lot of USB chips, but high-speed USB is not very DIY friendly. Also, a friend of mine who professionally writes USB2 drivers told me to stay the hell away from it.
Eh ? I have 100 Mbps running on the Suzaku, no problem at all, and I'm quite confident I can do the same with the NGW100 ; the choice I'm facing now is, can I do it with Linux (I'd like to keep Linux) or will I have to go stand-alone ?
The reason I'm ditching the Suzaku isn't that it can't handle the throughput, it's the damn 48 KB of BRAM ; I can't put an extra line of code and I still need more features.
A lot of work, would it get finished ? I prefer OEM modules...
I thought FPGAs were hard, then tried ; it took me av evening to write a multichannel configurable parallel to I2S encoder...
Hello peufeu,
How's the work on the atmel board coming along? Too long this thread got no updates 🙂..
How's the work on the atmel board coming along? Too long this thread got no updates 🙂..
audiosteve said:
Hi Steve,
I have just stumbled over this thread in this forum, when I was looking into different means to transfer audio over ethernet...
I have a specific question regarding your CobraNet-stuff, but I'm so far unable to write emails on this forum (since I joined brand-new ;-), so I'd be glad if you could contact me instead...
Best regards,
Tobias
Ethernet AV
There is a new Ethernet standard emerging in the networking world. It will require switches equipped with special newer generation chips, but it will be able to handle low latency multichannel audio and video over standard (edit) CAT5e or CAT6. The higlights are:
2ms latency over up to 7 switch hops,
low jitter, central clocking,
easy user configuration.
It's called Ethernet AV and the underlying hardware is already in production. The new generation of switches and devices equipped with the Ethernet AV chips should emerge this year.
Here is a link to a pdf slide show that highlights the important points of the technology.
http://ieee802.org/1/files/public/docs2006/avb-mjt-EthernetAV-summary-060425.pdf
There is a new Ethernet standard emerging in the networking world. It will require switches equipped with special newer generation chips, but it will be able to handle low latency multichannel audio and video over standard (edit) CAT5e or CAT6. The higlights are:
2ms latency over up to 7 switch hops,
low jitter, central clocking,
easy user configuration.
It's called Ethernet AV and the underlying hardware is already in production. The new generation of switches and devices equipped with the Ethernet AV chips should emerge this year.
Here is a link to a pdf slide show that highlights the important points of the technology.
http://ieee802.org/1/files/public/docs2006/avb-mjt-EthernetAV-summary-060425.pdf
Can you please tell us names and model numbers of underlying hardware in now in production for Ethernet AV? I would be surprised if this is true as the AVB and AVBTP IEEE committees are still very much still hashing these new standards out. If they have made more progress than this I would be very interested to know. The whole thing that I don't like about these emerging standards are the requirements for specialized switches and MACs. This would be much more attractive (IMHO) if it worked using standard infrastructure.
Do a google search "Ethernet AV site:broadcom.com"
you will find a lot of actual Ethernet AV capable switches as well as references to chips that manufacturers can use for incorporation in their AV equipment.
google search
you will find a lot of actual Ethernet AV capable switches as well as references to chips that manufacturers can use for incorporation in their AV equipment.
google search
Interesting. Perhaps I will use that when it comes out. It looks like they got most of the stuff right, like FireWire, only better.
PCB for the ethernet FPGA modules goes to fabrication on monday next week, by the way.
PCB for the ethernet FPGA modules goes to fabrication on monday next week, by the way.
I got the spark fun reflow oven kit.
I have created a private forum for discussing about the project. Those who want to participate actively may send me an email.
FireWire :
After all, seems that the Dice manufacturers don't really want us to get an eval board for less than $1500.
I have created a private forum for discussing about the project. Those who want to participate actively may send me an email.
FireWire :
After all, seems that the Dice manufacturers don't really want us to get an eval board for less than $1500.
Status :
- FPGA+Ethernet proto board : Waiting for stencil and reflow oven
- DICE II FireWire proto board : Firmware license should be obtained. Design/Layout in progress.
- FPGA+Ethernet proto board : Waiting for stencil and reflow oven
- DICE II FireWire proto board : Firmware license should be obtained. Design/Layout in progress.
What happened?
Did this project die? It is really a shame if it did as it looked like a a great idea and nice implementation
Did this project die? It is really a shame if it did as it looked like a a great idea and nice implementation
peufeu disappeared for a while, so things really slowed down. But he reappeared recently, so there may be some movement on this project.
I know this is an old thread, but get ready for AVB as it's here now (almost). The only thing missing are PCIe NIC cards, but just wait a month or two. The controller chips exist.
Audio Video Bridging (AVB) ISE 2011 Interop (Avid, Harman, Lab X, and Marvell) - YouTube
Audio Video Bridging (AVB) ISE 2011 Interop (Avid, Harman, Lab X, and Marvell) - YouTube
XMOS has an AVB ref design and I think you can get boards from DigiKey.
Cirrus logic also has the CobraNet chips and AtteroTech has modules available for that. And Audinate has their Dante technolgy with modules available for that. For DIY CobraNet or the XMOS ref design ar probably the way to go. If you are looking to transport audio over ethernet in real time, rather than use SPDIF, then technology already exists that also operates as a scalable network, not just a spdif replacement. There is no need to re-invent the wheel on this. BTW, that Broadcom part linked to above is a MAC/PHY with a PCI I/F, not an AVB controller; although it natively supports some of the AVB bits like 1588 and Qav.
Cirrus logic also has the CobraNet chips and AtteroTech has modules available for that. And Audinate has their Dante technolgy with modules available for that. For DIY CobraNet or the XMOS ref design ar probably the way to go. If you are looking to transport audio over ethernet in real time, rather than use SPDIF, then technology already exists that also operates as a scalable network, not just a spdif replacement. There is no need to re-invent the wheel on this. BTW, that Broadcom part linked to above is a MAC/PHY with a PCI I/F, not an AVB controller; although it natively supports some of the AVB bits like 1588 and Qav.
- Status
- Not open for further replies.