If the requirements for well working CobraNet are not tighter than it works well on normally trafficked large network (hundreds or thousands of nodes) then you don’t need special NIC. If, on the other hand, it doesn’t work in such environment then, IMHO, the technical marketing information about it is not right because in practice it will need a separate, dedicated, specially configured (only certain equipment allowed) network. That it works on small idle network consisting of few NICs on single non-buffering switch is irrelevant.
This thread is very interesting. USB has asynchronous isochronous modes, and if you use a TAS1020 you can program it for such mode and clock FIFO out with the local clock. Because it is a USB Audio chip, it runs on any computer with the built-in driver, and you don't have to write a driver. On the other hand, it is very difficult to write the firmcode to do the asynch mode, and I only know of Wavelengthaudio to have done that.
My plan for the moment is to work from one of the FTDI chips as they are easy to use, and the speed should be OK for 24/96 stereo, assuming sufficient FIFOs. However, a driver then has to be written that runs in kernel mode interfacing this with the audio subsystem as there could be latency issues in accessing the USB drivers through the usermode API--what's worse than buffer underrun... Much easier in Linux than Windows, which also needs different drivers for XP and for Vista (and for XP my understanding is that kmixer always messes with the stream regardless of settings, so that means an ASIO driver is also needed here).
USB2 is interesting because you can do the upsampling on the PC and stream right to the D/A core, thus not have to use a fixed digital filter. How much such flexibility is worth, I'm not sure, as I don't know how good the digital filter ICs are. The one integrated in the PCM1794 DAC lists 130 dB stop mode attenuation, 0.00001 dB passband ripple, and 55/fS group delay. The first two look good, but I don't know what the effect of the group delay is. Is it constant or frequency dependent, what kind of audible effect does it cause for say fS 96 kHz, etc.
My plan for the moment is to work from one of the FTDI chips as they are easy to use, and the speed should be OK for 24/96 stereo, assuming sufficient FIFOs. However, a driver then has to be written that runs in kernel mode interfacing this with the audio subsystem as there could be latency issues in accessing the USB drivers through the usermode API--what's worse than buffer underrun... Much easier in Linux than Windows, which also needs different drivers for XP and for Vista (and for XP my understanding is that kmixer always messes with the stream regardless of settings, so that means an ASIO driver is also needed here).
USB2 is interesting because you can do the upsampling on the PC and stream right to the D/A core, thus not have to use a fixed digital filter. How much such flexibility is worth, I'm not sure, as I don't know how good the digital filter ICs are. The one integrated in the PCM1794 DAC lists 130 dB stop mode attenuation, 0.00001 dB passband ripple, and 55/fS group delay. The first two look good, but I don't know what the effect of the group delay is. Is it constant or frequency dependent, what kind of audible effect does it cause for say fS 96 kHz, etc.
> However, a driver then has to be written that runs in kernel mode
That's why I used Ethernet...
About hard digital filters : important things are, also, the number of coefficients, how they are quantized, the number of bits in the accumulator, use of dither...
On a PC you' use floating point. You could also do oversampling with FFTs (a la BruteFIR).
That's why I used Ethernet...
About hard digital filters : important things are, also, the number of coefficients, how they are quantized, the number of bits in the accumulator, use of dither...
On a PC you' use floating point. You could also do oversampling with FFTs (a la BruteFIR).
I think with USB there's less chance of one getting buffer underrun because of latency issues, despite the lower overall throughput. Plus, everyone has spare USB ports. If I succeed with the drivers, I'll make them open for others to use. Mostly it's an issue with Windows; under Linux it's much easier to do.
I'm wondering whether the filters such as the one integrated in the PCM1794 are "good enough", in the sense that any problems would be swamped under the distortion from the DAC and analog stages. If so, there's no point in using a DSP or software filter.
I'm wondering whether the filters such as the one integrated in the PCM1794 are "good enough", in the sense that any problems would be swamped under the distortion from the DAC and analog stages. If so, there's no point in using a DSP or software filter.
With USB Audio standard interface, it's just a matter of programming the firmcode in a controller to implement the standard with asynchronous isochronous mode, and then you have two things: asynch so the DAC does flow control, and guaranteed latency so very short buffers can be used! This is definitely the optimal solution. You don't even need drivers on the PC side since all modern PCs have USB Audio drivers already. And soon USB Audio for USB2.0 will be standardized, so higher speed for multichannel 24/192 becomes possible.
That’s right – this is the strength of two-way transport protocol with handshaking such as USB, FireWire, and Ethernet (if done right). You don’t need to send clock tics at all. You send a number telling the receiver (a DAC in this case) what sampling frequency to apply to incoming data values. Then you send the value stream somewhat faster than that. Then the receiver stops you when its buffer is full and starts you again when the buffer can take more numbers. No jitter, no problems, no clocks except the one in DAC. Minimum (and maximum) buffer size depends on what latency can practically be expected, small for FireWire, a little larger for USB, and quite large for Ethernet. This is how we have been doing things in computers for decades (using serial ports to beginning with). This is how S/PDIF and alike should have been defined by the big boys. They didn’t, they still don’t get it.
http://nicta.com.au/director/research/projects/dante.cfm
This already works and in case of the Macintosh computer it uses a custom driver to stream audio using a generic network card.
Windows drivers are in the works.
Future Dolby Lake DSP processors will have it built in. Users will be able to pick audio from anywhere on the network.
This already works and in case of the Macintosh computer it uses a custom driver to stream audio using a generic network card.
Windows drivers are in the works.
Future Dolby Lake DSP processors will have it built in. Users will be able to pick audio from anywhere on the network.
Hi,
I've just read through this thread and I'm quite impressed!
I'm about to build something that very well be built upon your ideas! But your homepage, peufeu? When is it available? I'd like to look at your design in detail!
The system I'm thinking about is a two by five ways FIR-filter, possible with room-correction, using BruteFIR and other stuff I've recently discovered (((accurate))). I've got a analog five-way horn loudspeakers system, and have been thinking a long time about implementing corrections for time delays between the different drivers.
/Bosse
I've just read through this thread and I'm quite impressed!
I'm about to build something that very well be built upon your ideas! But your homepage, peufeu? When is it available? I'd like to look at your design in detail!
The system I'm thinking about is a two by five ways FIR-filter, possible with room-correction, using BruteFIR and other stuff I've recently discovered (((accurate))). I've got a analog five-way horn loudspeakers system, and have been thinking a long time about implementing corrections for time delays between the different drivers.
/Bosse
Bokser, that sounds interesting. Correcting time delays between drives doesn’t require FIR or other filters. You need to delay signal to the drives that come “first”. A simple FIFO buffer of appropriate for delay and sample rate length is all what’s needed. You put samples at one buffer end and you pick up samples at the other. Number of samples in-between (divided by sampling frequency) gives the delay.
/Mikael
/Mikael
I ordered this marvelous board today :
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4102
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4102
Atmel board
peufeu,
I noticed you are willing to try the board I suggested in a previous post.
http://www.diyaudio.com/forums/showthread.php?postid=1180549#post1180549
It seems to be very cheap and powerfull, and probably we can set up both usb and ethernet input. However I was not sure it can be used for your purpose... my hardware expertise is pretty low.
Please keep us posted on your progress with this board!
regards
Emanuele
peufeu,
I noticed you are willing to try the board I suggested in a previous post.
http://www.diyaudio.com/forums/showthread.php?postid=1180549#post1180549
It seems to be very cheap and powerfull, and probably we can set up both usb and ethernet input. However I was not sure it can be used for your purpose... my hardware expertise is pretty low.
Please keep us posted on your progress with this board!
regards
Emanuele
@Thunau
Did you have the chance to try Dante yourself or do you refer to the press information released by audinate?
The published technical specs are quite ambitious; it claims to have the flexibility and standard ethernet compliance of CobraNet and to surpass the performance of the proprietary point-to-point interface of AES50, all with Zeroconf functionality.
I'm sorry, but I won't believe that til I have a test setup working on my desk.
Did you have the chance to try Dante yourself or do you refer to the press information released by audinate?
The published technical specs are quite ambitious; it claims to have the flexibility and standard ethernet compliance of CobraNet and to surpass the performance of the proprietary point-to-point interface of AES50, all with Zeroconf functionality.
I'm sorry, but I won't believe that til I have a test setup working on my desk.
hwb said:
I work for a large audio touring and installations company. We met with Dolby Lake engineers regarding their future products and to discuss our wish list of features a few months ago.
That's when they told us about Dante and its features. I haven't seen prototypes, but I have no reason to doubt their word (that the Dante software exists and works) These guys are not in marketing, they write software and build processors- damn good ones too.
I'm waiting to get my hands on some boxes just like you.
Peufeu, what kind of network protocol do you have in mind, IP or something own? Using IP easies programming on the host but may be more work on device depending on how much ready to use support is there on the board. Keeping it as high as TCP allows you to simply read a stream and leave all handshaking to TCP layer and below. UDP requires handshaking programming.
Also, do you think in terms of one board with 2 – 6 channels and DACs (or digital outputs in my case) or in terms of 2 – 6 boards with own single channel each? The former should be straight forward to realize (apart from all the work that has to be done), the latter is more difficult from theoretical point of view because of synchronization issues. The former requires more CPU power per card than the latter.
On 100 Mbps Ethernet I don’t think the bandwidth will be a problem – my 3 years old notebook sustains 45 Mbps throughput, which is twice as much as needed for 8 channels of 24 bits 192 kHz audio.
Also, do you think in terms of one board with 2 – 6 channels and DACs (or digital outputs in my case) or in terms of 2 – 6 boards with own single channel each? The former should be straight forward to realize (apart from all the work that has to be done), the latter is more difficult from theoretical point of view because of synchronization issues. The former requires more CPU power per card than the latter.
On 100 Mbps Ethernet I don’t think the bandwidth will be a problem – my 3 years old notebook sustains 45 Mbps throughput, which is twice as much as needed for 8 channels of 24 bits 192 kHz audio.
Of course, 1 board with N channels !
My prototype uses UDP packets. It works very well. The protocol is custom, but pretty simple, nothing fancy.
- Device sends UDP packet to PC every millisecond with information about how many bytes it has played, and how many bytes remain in its buffer. It can also send audio data from an ADC.
- PC uses this data, computes how many bytes must be sent, and either waits or sends data packets.
- Data packets sent by the PC can contain audio data (obviously) and also various commands, notably the infamous Peek/Poke which allow remote control of the hardware by writing to memory addresses in the device. I had to do this since there was not enough memory in the device to program a real RPC, so things like "set number of channels" are implemented as remote Poke commands.
I could have used RAW Ethernet packets, but :
- UDP means my "driver" is a simple userspace program, running non-root, writing to a datagram socket like any other network application. (RAW ethernet needs to be root)
- Parsing an UDP packet is really simple and adds maybe 10-20 lines of code insid the device, so it is really worth it.
TCP flow control, on the other hand, means you must use a TCP stack, either running embedded linux or lwip ; either way more overhead. I could not run this on this little board, since the BRAM available for code is way too small, and the Microblaze CPU way too slow.
UDP has no delivery guarantee. In practice, I have never seen a lost packet. As long as you don't use a collision-prone topology, packet loss simply does not occur.
From the specs of the Atmel board, I believe I could use the embedded Linux and straight TCP. This would definitely simplify things a lot !
We will see.
My prototype uses UDP packets. It works very well. The protocol is custom, but pretty simple, nothing fancy.
- Device sends UDP packet to PC every millisecond with information about how many bytes it has played, and how many bytes remain in its buffer. It can also send audio data from an ADC.
- PC uses this data, computes how many bytes must be sent, and either waits or sends data packets.
- Data packets sent by the PC can contain audio data (obviously) and also various commands, notably the infamous Peek/Poke which allow remote control of the hardware by writing to memory addresses in the device. I had to do this since there was not enough memory in the device to program a real RPC, so things like "set number of channels" are implemented as remote Poke commands.
I could have used RAW Ethernet packets, but :
- UDP means my "driver" is a simple userspace program, running non-root, writing to a datagram socket like any other network application. (RAW ethernet needs to be root)
- Parsing an UDP packet is really simple and adds maybe 10-20 lines of code insid the device, so it is really worth it.
TCP flow control, on the other hand, means you must use a TCP stack, either running embedded linux or lwip ; either way more overhead. I could not run this on this little board, since the BRAM available for code is way too small, and the Microblaze CPU way too slow.
UDP has no delivery guarantee. In practice, I have never seen a lost packet. As long as you don't use a collision-prone topology, packet loss simply does not occur.
From the specs of the Atmel board, I believe I could use the embedded Linux and straight TCP. This would definitely simplify things a lot !
We will see.
This CPU has a high-speed SPI interface with DMA ; in that case the smallest Xilinx FPGA - about $9 - will do nicely as a demuxer to I2S streams. Soldering TQFP is not my definition of bliss but it's pretty doable.
OK, I have a FPGA already, so why use a CPU and a FPGA ? Simple :
- Microblaze sucks, it's dog slow
- Microblaze needs Xilinx XPS software which is a bug nest
- The Suzaku sucks too, I get 16 KB to put my code ! I can't put code in SDRAM for some reason (probably bug) ; it's too slow anyway
- I need a real CPU with enough power, space to put my code to implement the interesting features, like displaying the song name on LCD, handling user interface, etc
- I'd like to do oversampling in the FPGA but I can't, all the buffers are used.
For this project the best thing is to team up a real CPU with an FPGA.
The best implementation would be :
- FPGA
- Ethernet PHY directly connected to the FPGA, soft MAC core
- SRAM directly connected to the FPGA (about 1 Megabyte is enough)
- A real CPU with flash, and local RAM
In this case the FPGA would handle the data transfers and the CPU would only act as the Boss. The CPU would not have to move around the data packets. It would just parse the headers and handle the intelligence, then tell the FPGA to copy data to buffer.
Unfortunately I found no such board, at reasonable prices.
OK, I have a FPGA already, so why use a CPU and a FPGA ? Simple :
- Microblaze sucks, it's dog slow
- Microblaze needs Xilinx XPS software which is a bug nest
- The Suzaku sucks too, I get 16 KB to put my code ! I can't put code in SDRAM for some reason (probably bug) ; it's too slow anyway
- I need a real CPU with enough power, space to put my code to implement the interesting features, like displaying the song name on LCD, handling user interface, etc
- I'd like to do oversampling in the FPGA but I can't, all the buffers are used.
For this project the best thing is to team up a real CPU with an FPGA.
The best implementation would be :
- FPGA
- Ethernet PHY directly connected to the FPGA, soft MAC core
- SRAM directly connected to the FPGA (about 1 Megabyte is enough)
- A real CPU with flash, and local RAM
In this case the FPGA would handle the data transfers and the CPU would only act as the Boss. The CPU would not have to move around the data packets. It would just parse the headers and handle the intelligence, then tell the FPGA to copy data to buffer.
Unfortunately I found no such board, at reasonable prices.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.