Yep,
It has I2S natively output from the IBM STB02500 chip which is the Power PC chip designed for set top boxes.
This goes to a PCM1725 DAC which accepts I2S inputs - so tapping off the I2S from here should be straightforward
I'm not sure about SPI for multichannel audio - but it has synchronous serial interface. It also has I2C input.
I hope this isn't thread jacking but here's the datasheet http://www.datasheets.org.uk/search.php?q=STB02500&sType=part
Would love to know what Pierre thought of it
John
It has I2S natively output from the IBM STB02500 chip which is the Power PC chip designed for set top boxes.
This goes to a PCM1725 DAC which accepts I2S inputs - so tapping off the I2S from here should be straightforward
I'm not sure about SPI for multichannel audio - but it has synchronous serial interface. It also has I2C input.
I hope this isn't thread jacking but here's the datasheet http://www.datasheets.org.uk/search.php?q=STB02500&sType=part
Would love to know what Pierre thought of it
John
Thanks for the link !
I received ATNGW100 board. Unfortunately I'll need a null modem cable to use it (should get that shortly). I'll see what I can do with that.
It has I2S output, too, so doing Ethernet -> stereo at up to 96k should be pretty straightforward.
However multichannel 24-192 for active crossover will need another output port. The SPI port can handle the bandwidth, I'll use this.
The set top box thing looks interesting, too, since it is more powerful. (thanks for the email !) However, it is probably less versatile (how to get access to some I/O lines, especially high speed IO for multichannel audio ?)
Another solution (much cheaper than the set top box) would be to use a Linux open source router (Linksys has one) which can be had for € 50 and obviously have ethernet ports. I don't know about the IO features on these boxes though.
Can you post a pic of the inside of your box ?
I received ATNGW100 board. Unfortunately I'll need a null modem cable to use it (should get that shortly). I'll see what I can do with that.
It has I2S output, too, so doing Ethernet -> stereo at up to 96k should be pretty straightforward.
However multichannel 24-192 for active crossover will need another output port. The SPI port can handle the bandwidth, I'll use this.
The set top box thing looks interesting, too, since it is more powerful. (thanks for the email !) However, it is probably less versatile (how to get access to some I/O lines, especially high speed IO for multichannel audio ?)
Another solution (much cheaper than the set top box) would be to use a Linux open source router (Linksys has one) which can be had for € 50 and obviously have ethernet ports. I don't know about the IO features on these boxes though.
Can you post a pic of the inside of your box ?
Well, the board was bricked due to a buggy firmware version. Fortunately the thing is well thought out : I downloaded the new firmware from atmel, imaged it on a SD card, put the SD in the NGW100 slot, booted from the SD and upgraded the firmware. This is just copypasting a few lines of shell commands from the AVR wiki.
It works, it DHCPs, it pings, I can log into it via SSH or serial console, etc. It's very cute.
On the Suzaku, performance was really abysmal, due to the extremely slow and dumb SDRAM controller. This one behaves like you'd expect from an embedded 130 MHz 32-bit CPU with 32K of fast cache, it's snappy.
~ # cat /proc/cpuinfo
processor : 0
cpu family : AVR32B revision 1
cpu type : AP7000 revision 0
i-cache : 16K (4 ways x 128 sets x 32)
d-cache : 16K (4 ways x 128 sets x 32)
bogomips : 260.38
However, the network bandwidth isn't as high as I had hoped : about 2 megabytes/second. Granted, this is still way better than the Suzaku's 0.1 megabytes/second...
Linux's TCP stack and network drivers are quite good but not really up to scratch for this application since they involve lots of data copies (each packet is copied multiple times between the ethernet device and userspace memory). This isn't a problem when you have dual channel DDR2 SDRAM, but on embedded, it sucks.
I will see how to fix that to get enough bandwidth for multichannel 24-192.
However I'm pretty sure that I can install the alsa drivers (provided on the CDROM) and get some linux audio output directly.
It works, it DHCPs, it pings, I can log into it via SSH or serial console, etc. It's very cute.
On the Suzaku, performance was really abysmal, due to the extremely slow and dumb SDRAM controller. This one behaves like you'd expect from an embedded 130 MHz 32-bit CPU with 32K of fast cache, it's snappy.
~ # cat /proc/cpuinfo
processor : 0
cpu family : AVR32B revision 1
cpu type : AP7000 revision 0
i-cache : 16K (4 ways x 128 sets x 32)
d-cache : 16K (4 ways x 128 sets x 32)
bogomips : 260.38
However, the network bandwidth isn't as high as I had hoped : about 2 megabytes/second. Granted, this is still way better than the Suzaku's 0.1 megabytes/second...
Linux's TCP stack and network drivers are quite good but not really up to scratch for this application since they involve lots of data copies (each packet is copied multiple times between the ethernet device and userspace memory). This isn't a problem when you have dual channel DDR2 SDRAM, but on embedded, it sucks.
I will see how to fix that to get enough bandwidth for multichannel 24-192.
However I'm pretty sure that I can install the alsa drivers (provided on the CDROM) and get some linux audio output directly.
Do you mean something like this? http://omnima.co.uk/store/product.php?productid=16140&cat=254&page=1
General purpose controller/gateway embedded solution
- Supports Linux or NetBSD
- Supports Internet/ethernet connectivity for your project
- Supports USB host connectivity
- Embedded ethernet switch
- Write your embedded application using GNU tools
- Cost effective
- 12V power supply included
- Free 3-4 day shipping within UK mainland
Technical details
- Infineon ADM5120 based board
- 12/13 GPIO general purpose I/O ports available
- 1x UART serial port / programming port
- 1x JTAG programming/debugging port
- Pin headers provided for the UART/JTAG connections
- 2MB Flash / 16MB RAM
- 12V power supply included
Note: This is an OEM-only product. There is no enclosure included with this item.
General purpose controller/gateway embedded solution
- Supports Linux or NetBSD
- Supports Internet/ethernet connectivity for your project
- Supports USB host connectivity
- Embedded ethernet switch
- Write your embedded application using GNU tools
- Cost effective
- 12V power supply included
- Free 3-4 day shipping within UK mainland
Technical details
- Infineon ADM5120 based board
- 12/13 GPIO general purpose I/O ports available
- 1x UART serial port / programming port
- 1x JTAG programming/debugging port
- Pin headers provided for the UART/JTAG connections
- 2MB Flash / 16MB RAM
- 12V power supply included
Note: This is an OEM-only product. There is no enclosure included with this item.
Hm, this one is incredibly cheap ! You know, I've always wanted to put ethernet connectivity in gear (like : build ethernet connected measurement instruments, or house light control, etc) but the ethernet <-> GPIO modules that are available are always very expensive and/or suck. This one would be perfect (except it's big). (Ethernet is good for those applications because of the cable length and transformer isolation). But there is no way to get the data out of the board ; and it's a hardware switch, I'm not sure it can do anything with data packets except switch them.
Anyway, for our Ethernet Audio Gear Project, we have actually two different projects :
- Low bandwidth : be able to play 2 channels at 16b 44.1k (=176 kB/s), or even 24b 192k (=1152 kB/s).
These would use less than 10 Mbps. Say, 12 Mbps with overhead.
For this, you need a board with Ethernet, a I2S output, a powerful enough CPU, and some RAM. The ATNGW100 fits this description perfectly, and it's cheap and available. I'm pretty much certain that if I installed the alsa driver for its I2S input and aplayer on the board I'd be able to play FLAC files from a Samba network share on my PC. In other words, a Squeezebox, but with open firmware, that you can customize at will.
I'm not interested in such a project (I'd rather buy a Squeezebox), although it certainly has potential !
- Then there is the high bandwidth variant : use the PC to do digital active crossover, oversampling to 192k or 176k, room correction and any other processing, and send 6, 8 or more channels of 24-192 audio to the board.
The board will also have an ADC and will send a sample stream to the PC.
This means (for 8 channels) about 36 Mbits/s, say 40 with overhead, from PC -> board, and 12 Mbps the other way.
This is what I am interested in.
There are two problems.
First, get the data from ethernet to onboard RAM buffers.
Either Linux is used, and data is copied multiple times as it goes through the TCP/IP stack and to the usermode application (this explains why the board has insuficient throughput, even though impressive for such a small CPU), or Linux is not used, and basically you just write the packets to SDRAM buffers as they come (which is a lot faster, that's what I did in the Suzaku). A third solution would be to have a FPGA with the opencores MAC core and an external PHY, connected to SDRAM or SRAM and a real CPU to control it. The FPGA could act as a big fat data processing engine, which is what FPGAs do best.
So, for my high bandwidth scenario, either i use Linux (in this case I need a powerful board, probably a PPC-400), or I don't (shouldn't be too hard to hit the hardware directly) or I find a FPGA board like above mentioned.
Second problem : get the data out to the DACs.
For stereo at low freqs, an I2S interface is adequate. For multichannel, no I2S interface is going to work, and this is where the problems start. There is SPI (high speed serial) which is good, there could also be parallel connections (GPIO) if DMA is usable on them, or memory-mapped IO if the bus is available. All three solutions need a $10 low-end Spartan FPGA to demux the stream into 8 I2S channels. This is pretty easy to do.
In the end, it all boils down to the ability to transfer data from ethernet to buffer RAM fast enough, and the ability to get this data out of buffer RAM and to the DACs fast enough.
Anyway, for our Ethernet Audio Gear Project, we have actually two different projects :
- Low bandwidth : be able to play 2 channels at 16b 44.1k (=176 kB/s), or even 24b 192k (=1152 kB/s).
These would use less than 10 Mbps. Say, 12 Mbps with overhead.
For this, you need a board with Ethernet, a I2S output, a powerful enough CPU, and some RAM. The ATNGW100 fits this description perfectly, and it's cheap and available. I'm pretty much certain that if I installed the alsa driver for its I2S input and aplayer on the board I'd be able to play FLAC files from a Samba network share on my PC. In other words, a Squeezebox, but with open firmware, that you can customize at will.
I'm not interested in such a project (I'd rather buy a Squeezebox), although it certainly has potential !
- Then there is the high bandwidth variant : use the PC to do digital active crossover, oversampling to 192k or 176k, room correction and any other processing, and send 6, 8 or more channels of 24-192 audio to the board.
The board will also have an ADC and will send a sample stream to the PC.
This means (for 8 channels) about 36 Mbits/s, say 40 with overhead, from PC -> board, and 12 Mbps the other way.
This is what I am interested in.
There are two problems.
First, get the data from ethernet to onboard RAM buffers.
Either Linux is used, and data is copied multiple times as it goes through the TCP/IP stack and to the usermode application (this explains why the board has insuficient throughput, even though impressive for such a small CPU), or Linux is not used, and basically you just write the packets to SDRAM buffers as they come (which is a lot faster, that's what I did in the Suzaku). A third solution would be to have a FPGA with the opencores MAC core and an external PHY, connected to SDRAM or SRAM and a real CPU to control it. The FPGA could act as a big fat data processing engine, which is what FPGAs do best.
So, for my high bandwidth scenario, either i use Linux (in this case I need a powerful board, probably a PPC-400), or I don't (shouldn't be too hard to hit the hardware directly) or I find a FPGA board like above mentioned.
Second problem : get the data out to the DACs.
For stereo at low freqs, an I2S interface is adequate. For multichannel, no I2S interface is going to work, and this is where the problems start. There is SPI (high speed serial) which is good, there could also be parallel connections (GPIO) if DMA is usable on them, or memory-mapped IO if the bus is available. All three solutions need a $10 low-end Spartan FPGA to demux the stream into 8 I2S channels. This is pretty easy to do.
In the end, it all boils down to the ability to transfer data from ethernet to buffer RAM fast enough, and the ability to get this data out of buffer RAM and to the DACs fast enough.
Pierre,
Thanks for the comprehensive & interesting explanation - can't say I understand all the hardware stuff but I will try and learn.
I understand that you are interested in multichannel audio for crossover, room correction, etc so my hardware suggestions are a distraction. Sorry about that - I got exited about a set top box which potentially could also serve up high quality audio & I thought of you.
So, your Atmel board will not do the multichannel task.
I will keep looking for suitable hardware - forgive me if I make silly suggestions along the way - it's just me on a learning curve
John
Thanks for the comprehensive & interesting explanation - can't say I understand all the hardware stuff but I will try and learn.
I understand that you are interested in multichannel audio for crossover, room correction, etc so my hardware suggestions are a distraction. Sorry about that - I got exited about a set top box which potentially could also serve up high quality audio & I thought of you.
So, your Atmel board will not do the multichannel task.
I will keep looking for suitable hardware - forgive me if I make silly suggestions along the way - it's just me on a learning curve
John
Oh, actually the Atmel board has a fast SPI output, powerful CPU, very smart DMA engine...
If it can get 2 MB/s under Linux TCP file transfer (wget actually) I'm quite certain that, without any OS (ie. custom code) it can do multichannel and exploit 100% of the ethernet bandwidth. Remember Linux copies all data coming from the network at least a few times, all using the CPU (no DMA !), plus TCP has some overhead also.
The difference with the Suzaku board will be that I'll get a lot more than 48KB to store my code and buffers, and I won't have to deal with the horrendous Xilinx XPS tool.
I could also (on the Atmel board) hack the ethernet driver to make it recognize the audio packets (I'd use UDP) and directly forward them to the audio ring buffer in SDRAM. This would allow me to keep a fully functional Linux system, which is nice (LIRC, volume control via HTTP, etc).
The Atmel CPU gives its smart DMA controller a linked list of buffers to store incoming packets, and the DMA engine apparently handles everything all by itself (I think, from the docs). So the only thing that matters is the SDRAM throughput which is more than adequate. This is very different from the Suzaku where network data must be extracted from the MAC chip through a very slow asynchronous bus which is shared with the RAM !
If it can get 2 MB/s under Linux TCP file transfer (wget actually) I'm quite certain that, without any OS (ie. custom code) it can do multichannel and exploit 100% of the ethernet bandwidth. Remember Linux copies all data coming from the network at least a few times, all using the CPU (no DMA !), plus TCP has some overhead also.
The difference with the Suzaku board will be that I'll get a lot more than 48KB to store my code and buffers, and I won't have to deal with the horrendous Xilinx XPS tool.
I could also (on the Atmel board) hack the ethernet driver to make it recognize the audio packets (I'd use UDP) and directly forward them to the audio ring buffer in SDRAM. This would allow me to keep a fully functional Linux system, which is nice (LIRC, volume control via HTTP, etc).
The Atmel CPU gives its smart DMA controller a linked list of buffers to store incoming packets, and the DMA engine apparently handles everything all by itself (I think, from the docs). So the only thing that matters is the SDRAM throughput which is more than adequate. This is very different from the Suzaku where network data must be extracted from the MAC chip through a very slow asynchronous bus which is shared with the RAM !
SunRa said:
SunRa, could you please elaborate this topic a little more? I have a little difficult to see in what way a transformer could limit noise. AFAIK, it eliminates any DC offset, but noise? Also, because USB is digital, it is not sensitive to noise at all, until the noise level is so high that the reception of the digital signal itself is impossible.
Hello mhakman,
I guess I was not too specific.
Ok, this is how I understand it. USB has no isolation method as far as I know. If USB is used, that means the atmel board and the dac will share a common ground with the PC, and there is the posibility of all kinds of artefacts from PC, go through the dac.
Of course I might be wrong...
I guess I was not too specific.
Ok, this is how I understand it. USB has no isolation method as far as I know. If USB is used, that means the atmel board and the dac will share a common ground with the PC, and there is the posibility of all kinds of artefacts from PC, go through the dac.
Of course I might be wrong...
If analog side of DAC is not galvanically isolated from its digital side then theoretically you could get some noise over from digital side (i.e. from PC) to the analog side. You would need quite large spikes to beginning with, I think. Assuming the same probability of such large spike appearing on PC’s USB connector as on its Ethernet port (before transformer) then such a spike would make its way through transformer(s) too. The question is whether a spike of this size would cause all sorts of weird things in the PC itself.
I have been using USB connected DAC for few years now, and when listening at 90 dB through studio earphones I never heard any noise except clicks and breaks when I choose too small buffers with respect to PC’s performance and load.
Optically isolated USB cables sound interesting
Perhaps one could build them using of-the-shelf Toslink components 
Audiosteve, could you explain what common mode noise is, please?
I have been using USB connected DAC for few years now, and when listening at 90 dB through studio earphones I never heard any noise except clicks and breaks when I choose too small buffers with respect to PC’s performance and load.
Optically isolated USB cables sound interesting
Perhaps one could build them using of-the-shelf Toslink components Audiosteve, could you explain what common mode noise is, please?
The main reason transformer coupling is good for ethernet is that it breaks the ground loop :
mains ground -> PC chassis -> digital cable -> DAC -> amplifier chassis -> mains ground
If the PC is not in the listening room (for obvious fan / HDD noise reasons), this ground loop would include all the mains wiring from the two different mains sockets (for the PC and amplifier) up to the mains earth distribution in the house.
Ethernet is specified for up to 100 m, this is why transformer isolation is vital : otherwise it would make huge ground loops !
mains ground -> PC chassis -> digital cable -> DAC -> amplifier chassis -> mains ground
If the PC is not in the listening room (for obvious fan / HDD noise reasons), this ground loop would include all the mains wiring from the two different mains sockets (for the PC and amplifier) up to the mains earth distribution in the house.
Ethernet is specified for up to 100 m, this is why transformer isolation is vital : otherwise it would make huge ground loops !
To answer mhakman's question. Common mode noise is noise that exists on both lines of the signal path (+/-). The RJ45 is transformer coupled and a differential input. So noise that appears on both lines (common to both) is canceled out. Provides a cleaner signal for the Ethernet receiver. It's the same idea as when using balanced lines in analog audio.
Peufeu, Audiosteve, yes, of course, I’m sure too that transformers and differential cabling are good for distribution of analog signals in long cables. At the very bottom of it, the Ethernet is analog, as are V92 modem, DSL, FM radio, DVB, and more – frequency and/or phase modulation is analog. Transformers and differential cabling make Ethernet more reliable and allow using longer cables than would be possible otherwise. However, this low-level, high-frequency, analog signal is then used for transmission of much slower digital signal, which in audio case is in turn used for transmission of yet slower analog audio signal. Furthermore, the actual question was not whether to use transformers on Ethernet or not, but in what way, if any, USB would be better or worse than Ethernet for getting digital audio signal out of a PC.
I asked whether using USB rather than Ethernet would require less processing power at the receiving device because Peufeu had clear performance problems when experimenting with Ethernet/IP on the Atmel board. This issue was then answered by an assertion stating that Ethernet is better than USB because Ethernet uses transformers and therefore it reduces the audio noise (as compared to USB). Now, there may be arguments for preferring Ethernet over USB but transformers aren’t one of those, IMHO. Also, my original question remains, would USB require less processing power than Ethernet?
I asked whether using USB rather than Ethernet would require less processing power at the receiving device because Peufeu had clear performance problems when experimenting with Ethernet/IP on the Atmel board. This issue was then answered by an assertion stating that Ethernet is better than USB because Ethernet uses transformers and therefore it reduces the audio noise (as compared to USB). Now, there may be arguments for preferring Ethernet over USB but transformers aren’t one of those, IMHO. Also, my original question remains, would USB require less processing power than Ethernet?
Processing power required is about the same.
USB is much harder to code for (you need to code a driver in the PC versus a socket for ethernet, the specs are a lot more complex etc). Ethernet only needs a socket on the PC. Code on the device will also be more complex for USB.
Ethernet is more DIY-friendly.
The selling point of the transformer for ethernet audio is to isolate the DAC's analog ground from the PC ground. You can also do this with optos, on USB.
USB is much harder to code for (you need to code a driver in the PC versus a socket for ethernet, the specs are a lot more complex etc). Ethernet only needs a socket on the PC. Code on the device will also be more complex for USB.
Ethernet is more DIY-friendly.
The selling point of the transformer for ethernet audio is to isolate the DAC's analog ground from the PC ground. You can also do this with optos, on USB.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.