peufeu,
would your prototype hold for ten channels?
I suspect a must is a dedicated ethernet segment between the PC and the device, or?
would your prototype hold for ten channels?
I suspect a must is a dedicated ethernet segment between the PC and the device, or?
I have not tested anything other than stereo 16/88.2 with audio in real life since that's what my DAC does, but I did test the network and UDP system and yes, the device did manage full 100 Mbps bandwidth without problem, so I guess your channel count would be OK.
Having BruteFIR process that in 192 kbps might need some CPU power though !
re the dedicated ethernet segment : yeah, don't share it with your fileserver. A 5€ realtek NIC works nicely.
Having BruteFIR process that in 192 kbps might need some CPU power though !
re the dedicated ethernet segment : yeah, don't share it with your fileserver. A 5€ realtek NIC works nicely.
Peufeu, the reason I’m asking for your thoughts about protocol is that I could be interested in using this board to build a multi-channel digital audio interface to PC/Mac, if I don’t find ready-to-use device or board (Firewire or USB or Net to 8 digital channels in and out). This application would require a lot of common development, both soft- and hardware, with the application that you are building. The difference is using digital sound transceivers instead of DACs and ADCs. I’m proficient in software development, both host and embedded but not in hardware development at your level. So my thinking is maybe there is a possibility to split the work among us two? Among other things I would need to develop device drivers for the host, first ASIO but then also Active Sound and/or Core Audio so that any host application could use the card. Such a driver would “talk” to the card using network in this case. I also noticed that the card supports hardware accelerated Java execution and development tools run under Eclipse – both are my preferred choices. What do you think?
The question of 1 board with N channels vs. N boards steams from possibility of building-in single-channel boards into active speakers. Combine that with wireless network and you have surround system for the 21st century. Imagine six active wireless high quality loudspeakers and a wireless notebook computer with music library, DVD player and perhaps a DVB card. No other equipment and no cables except power would be needed (well, you still need that big flat panel). To paraphrase Sun: the computer is the AV receiver!
The question of 1 board with N channels vs. N boards steams from possibility of building-in single-channel boards into active speakers. Combine that with wireless network and you have surround system for the 21st century. Imagine six active wireless high quality loudspeakers and a wireless notebook computer with music library, DVD player and perhaps a DVB card. No other equipment and no cables except power would be needed (well, you still need that big flat panel). To paraphrase Sun: the computer is the AV receiver!
> The question of 1 board with N channels vs. N boards stems from possibility of building-in single-channel boards into active speakers.
Then you have a tiny problem with the clock, and you get into PLL and jitter territory. Also, Wi-Fi isn't, shall we say, low-latency... which will prevent video playback. I'm doing this to get the best possible audio quality...
> I could be interested in using this board to build a multi-channel digital audio interface to PC/Mac
Cool ! Is it a professional or personal project ?
RME and many others do this with FireWire, by the way.
> So my thinking is maybe there is a possibility to split the work among us two?
Sure ! I really appreciate that !
Since I'll use Linux on the PC, I will make a JACK driver for it. JACK is really neat, runs in userspace, and is easy to use. You can then connect it to any application that supports it (goal : player -> brutefir -> net -> DAC). It is similar to ASIO : it can connect audio apps together.
If you want to write Windows drivers, that's even better, since I won't touch that 😀
ASIO is similar to JACK (connecting apps) but also talks directly to the soundcard, unlike JACK which has no kernel drivers (it uses ALSA).
I think, if the CPU on the board I'll order can handle the bandwidth, the best solution would be to have the CPU and its very smart DMA engine forward data between Ethernet and, either the I2S interfaces (for low-cost, low channel count) or SPI for high channel-count. I can do a SPI <=> I2S converter easily with a low-cost FPGA, if you want SPDIF it will probably be possible to stick SPDIF cores in the FPGA too. And, as I said, maybe oversampling in the FPGA.
Then you have a tiny problem with the clock, and you get into PLL and jitter territory. Also, Wi-Fi isn't, shall we say, low-latency... which will prevent video playback. I'm doing this to get the best possible audio quality...
> I could be interested in using this board to build a multi-channel digital audio interface to PC/Mac
Cool ! Is it a professional or personal project ?
RME and many others do this with FireWire, by the way.
> So my thinking is maybe there is a possibility to split the work among us two?
Sure ! I really appreciate that !
Since I'll use Linux on the PC, I will make a JACK driver for it. JACK is really neat, runs in userspace, and is easy to use. You can then connect it to any application that supports it (goal : player -> brutefir -> net -> DAC). It is similar to ASIO : it can connect audio apps together.
If you want to write Windows drivers, that's even better, since I won't touch that 😀
ASIO is similar to JACK (connecting apps) but also talks directly to the soundcard, unlike JACK which has no kernel drivers (it uses ALSA).
I think, if the CPU on the board I'll order can handle the bandwidth, the best solution would be to have the CPU and its very smart DMA engine forward data between Ethernet and, either the I2S interfaces (for low-cost, low channel count) or SPI for high channel-count. I can do a SPI <=> I2S converter easily with a low-cost FPGA, if you want SPDIF it will probably be possible to stick SPDIF cores in the FPGA too. And, as I said, maybe oversampling in the FPGA.
Our company, Amplio Audio, is developing a multichannel soundcard for PC/Mac. I'd also be interested in sharing some of the burden in a project to develop a more universal product. We currently use a FireWire solution based on TI's ICELynx chips. This outputs I2S to our DAC/analog section. We feed this into amplifier modules for a complete solution. We have ASIO and multichannel WDM drivers, but currently contract the driver development to a 3rd party. We are also looking at another FireWire solution from TC Applied Technologies called DICE II. Numerous attempts to contact them have failed. I'd also like to explore an ethernet based solution.
see Ampliozone or Amplio Audio for more info.
or feel free to contact me at greggp@amplioaudio.com
see Ampliozone or Amplio Audio for more info.
or feel free to contact me at greggp@amplioaudio.com
Nice startup !
Well, I had an email with the DiCE guys and it turns out that, while their product looks good, the price of the eval kit has an extra zero over what I'd pay for an eval board with 1 chip on it (it costs $1500).
For your professional project, well, I think it's nice, I think audiophiles need this, it's long overdue, and I'd buy something like that if good enough !
You should call Linkwitz and make an Orion with digital crossover and a RJ45 socket.
With FireWire, you get very low latency, good reliability, short cable, no isolation. Same with USB except it's clunkier. SPDIF and ADAT are obsolete.
All these have the old SPDIF problem, ie : the master clock is in the PC. Uniess you use Asynchronous, or you somehow arrange for your gear to be the Firewire master and provide the ticks. So you have funky PLLs and jitter.
Ethernet will give you higher latencies ; however 20-50 ms should be doable which allows correct lipsynch with video stored on the PC. It was never designed for audio. However, Ethernet also gives you transformer isolation and allows you to put the PC wherever you like. If the PC runs BruteFIR, it will have fans. So, out of the listening room is good.
Thanks to the DRM frenzy and Vista madness, it will be impossible to play any HD contents on any Windoze PC for a few years, and I'll bet you that when it works, it will still suck. I bet it will just work (illegally) on Linux like DeCSS did.
Well, I had an email with the DiCE guys and it turns out that, while their product looks good, the price of the eval kit has an extra zero over what I'd pay for an eval board with 1 chip on it (it costs $1500).
For your professional project, well, I think it's nice, I think audiophiles need this, it's long overdue, and I'd buy something like that if good enough !
You should call Linkwitz and make an Orion with digital crossover and a RJ45 socket.
With FireWire, you get very low latency, good reliability, short cable, no isolation. Same with USB except it's clunkier. SPDIF and ADAT are obsolete.
All these have the old SPDIF problem, ie : the master clock is in the PC. Uniess you use Asynchronous, or you somehow arrange for your gear to be the Firewire master and provide the ticks. So you have funky PLLs and jitter.
Ethernet will give you higher latencies ; however 20-50 ms should be doable which allows correct lipsynch with video stored on the PC. It was never designed for audio. However, Ethernet also gives you transformer isolation and allows you to put the PC wherever you like. If the PC runs BruteFIR, it will have fans. So, out of the listening room is good.
Thanks to the DRM frenzy and Vista madness, it will be impossible to play any HD contents on any Windoze PC for a few years, and I'll bet you that when it works, it will still suck. I bet it will just work (illegally) on Linux like DeCSS did.
EqcoLogic has developed an adaptive cable EQ for extending Firewire to 100m, so the former distance limitations of Firewire are no longer a problem.
See http://www.eqcologic.com/ds/EQCO400T Prelim DS v1 3.pdf
Furthermore, 1394c will allow an Ethernet-Phy to be used to transmit Firewire over Cat5.
So Firewire isn't limited to desktop applications anymore, a fact that I appreciate very much.
See http://www.eqcologic.com/ds/EQCO400T Prelim DS v1 3.pdf
Furthermore, 1394c will allow an Ethernet-Phy to be used to transmit Firewire over Cat5.
So Firewire isn't limited to desktop applications anymore, a fact that I appreciate very much.
Take a look at this product -
CEntrance CE1105
The bottom half of this sandwich is a DICE II. I think CEntrance will sell it to me separately without having to purchase the whole product (I'm not interested in their soundcard section). I think the price could be negotiated down to something reasonable.
CEntrance CE1105
The bottom half of this sandwich is a DICE II. I think CEntrance will sell it to me separately without having to purchase the whole product (I'm not interested in their soundcard section). I think the price could be negotiated down to something reasonable.
> Then you have a tiny problem with the clock, and you get into PLL and jitter territory. Also, Wi-Fi isn't, shall we say, low-latency... which will prevent video playback.
Yes, of course, no 2 clocks run at exactly the same speed. If devices use their own clocks (which is good for jitter) then sooner or latter they will fall behind each other and loose sync if you play for long time enough. Conventional solution is centralized clock with associated distribution and jitter problems. However, there could be another solution to this problem. This could be to let the devices to use their own (good) clocks and resynchronize at silence intervals. Silence can be made shorter or longer without anybody noticing that. This should work well for music where you naturally have silence between the tracks. This would require specified absolute accuracy for each of the clocks.
Latency of wireless could be the problem (the newest wireless standards are better than the older ones) unless you send the video the same way because then you have the same latency even there so audio and video remains in sync.
However, the wireless is not a project that I have in mind right now; it was just a dream (thanks Phil for these words!).
> RME and many others do this with FireWire, by the way
So far I have been unable to find a ready-to-use external device connecting to a PC by any means and providing multichannel S/PDIF in form of a number of coax or optical ports. Maybe there is something in the professional studio and/or broadcasting market with corresponding prices. This is the reason why I’m considering building (or rather integrating out of available components) such device.
> Since I'll use Linux on the PC…
My heart is with Linux too. I do use and develop for Linux for networking and some embedded purposes and participate in Open Source when I have the time. I use and develop for PC and Mac too both in the personal and professional areas. There is so much good software used by so many people in this commercial world that it would be unwise to deny myself the candies (personal) and the profits (professional). There is a place and a season for everything.
Let us continue this when you have received the board and both of us are clearer on what we need/want/wish.
Regards/Mikael
Yes, of course, no 2 clocks run at exactly the same speed. If devices use their own clocks (which is good for jitter) then sooner or latter they will fall behind each other and loose sync if you play for long time enough. Conventional solution is centralized clock with associated distribution and jitter problems. However, there could be another solution to this problem. This could be to let the devices to use their own (good) clocks and resynchronize at silence intervals. Silence can be made shorter or longer without anybody noticing that. This should work well for music where you naturally have silence between the tracks. This would require specified absolute accuracy for each of the clocks.
Latency of wireless could be the problem (the newest wireless standards are better than the older ones) unless you send the video the same way because then you have the same latency even there so audio and video remains in sync.
However, the wireless is not a project that I have in mind right now; it was just a dream (thanks Phil for these words!).
> RME and many others do this with FireWire, by the way
So far I have been unable to find a ready-to-use external device connecting to a PC by any means and providing multichannel S/PDIF in form of a number of coax or optical ports. Maybe there is something in the professional studio and/or broadcasting market with corresponding prices. This is the reason why I’m considering building (or rather integrating out of available components) such device.
> Since I'll use Linux on the PC…
My heart is with Linux too. I do use and develop for Linux for networking and some embedded purposes and participate in Open Source when I have the time. I use and develop for PC and Mac too both in the personal and professional areas. There is so much good software used by so many people in this commercial world that it would be unwise to deny myself the candies (personal) and the profits (professional). There is a place and a season for everything.
Let us continue this when you have received the board and both of us are clearer on what we need/want/wish.
Regards/Mikael
On Wireless :
The ping time over wi-fi isn't that bad, but you get lost packets due to interference, so for real-time audio, you have to buffer enough data to cover the retransmission time... and you have to manage the retransmissions... whereas wired ethernet never loses a packet unless you use a topology unsuited for audio anyway (ie. overloaded link between two switches, for instance).
I tried to run my ethernet DAC over WiFi, it works for a few seconds, then fails due to lost packets. I don't handle retransmission, by the way, I should, but it works without it on wired !
On Clocks :
OK, suppose 2 clocks with 10 ppm accuracy ; listen to a 5 minute song, at the end, the clocks have drifted by 132 samples (at 44.1k), ie. the stereo image would shift by about 1 meter, considering 340 m/s speed of sound...
You're stuck with VCXO...
The ping time over wi-fi isn't that bad, but you get lost packets due to interference, so for real-time audio, you have to buffer enough data to cover the retransmission time... and you have to manage the retransmissions... whereas wired ethernet never loses a packet unless you use a topology unsuited for audio anyway (ie. overloaded link between two switches, for instance).
I tried to run my ethernet DAC over WiFi, it works for a few seconds, then fails due to lost packets. I don't handle retransmission, by the way, I should, but it works without it on wired !
On Clocks :
OK, suppose 2 clocks with 10 ppm accuracy ; listen to a 5 minute song, at the end, the clocks have drifted by 132 samples (at 44.1k), ie. the stereo image would shift by about 1 meter, considering 340 m/s speed of sound...
You're stuck with VCXO...
Ok, I should do the calculus before I suggest a non-conventional solution. It seems you would need 1 or even 0.1 ppm accuracy. Is this doable?
Another thought, the clock in GPS signal, how good is it? Given the speed of light and the fact that this clock is used to compute time difference for radio waves coming from different distances, this should be quite a good clock. Could all DAC clocks sync to that? BTW, it is wireless 😀
Another thought, the clock in GPS signal, how good is it? Given the speed of light and the fact that this clock is used to compute time difference for radio waves coming from different distances, this should be quite a good clock. Could all DAC clocks sync to that? BTW, it is wireless 😀
Yes, you could use a GPS clock, but the standard implementation to get a high quality clock from the noisy satellite signal is... a PLL+VCXO. (or just PLL+VCO if you're cheap)
Heh 😀
Heh 😀
Ok, I hope this thread is not dead because it's way to intersting
I wonder if you've noticed this board here:
M524C3
Even more intersting is that they've developed an ethernet MP3 player based on uClinux: MP3 player and here (some pics included) : uClinux based player .
Of course we don't want mp3, rather wav or flac, or those poore DAC's... but it's intersting that most of the work is done using uClinux well, at least for stereo playback.
I'm just a beginner (read wannabie) in AVR/FPGA so I find these pages very helpfull; Overall, don't you think that the Atmel ATNGW100 is even more powerfull and suitable for this than the ColdFire board? And the price is just 1/10th !
I wonder if you've noticed this board here:
M524C3
Even more intersting is that they've developed an ethernet MP3 player based on uClinux: MP3 player and here (some pics included) : uClinux based player .
Of course we don't want mp3, rather wav or flac, or those poore DAC's... but it's intersting that most of the work is done using uClinux well, at least for stereo playback.
I'm just a beginner (read wannabie) in AVR/FPGA so I find these pages very helpfull; Overall, don't you think that the Atmel ATNGW100 is even more powerfull and suitable for this than the ColdFire board? And the price is just 1/10th !
This board is $649.
Digi-key shipped the ANGW100. I can't wait.
I like your idea of gutting routers. Why not. After all, the ATNGW100 is a router !
Digi-key shipped the ANGW100. I can't wait.
I like your idea of gutting routers. Why not. After all, the ATNGW100 is a router !
Hello Pierre,
As far as I know, the Atmel (which is around 70 Euro, thus far cheaper than the ColdFire board) has just 2 I2S channel support. You have mentiond using FPGA for demuxing to multichannel. Well, how exactly do you plan doing that?
Oh, and by the way... do you plan using uClinux or the linux distro that cames with the Atmel?
If these questions are to early and I should wait the arival of the board... well, I understand 😀
Regards,
Florin
As far as I know, the Atmel (which is around 70 Euro, thus far cheaper than the ColdFire board) has just 2 I2S channel support. You have mentiond using FPGA for demuxing to multichannel. Well, how exactly do you plan doing that?
Oh, and by the way... do you plan using uClinux or the linux distro that cames with the Atmel?
If these questions are to early and I should wait the arival of the board... well, I understand 😀
Regards,
Florin
> As far as I know, the Atmel (which is around 70 Euro
Yeah, the price is good, although with shipping and tax it should be 75$ = 120€.
> You have mentiond using FPGA for demuxing to multichannel. Well, how exactly do you plan doing that?
Well, stick a little board on the expansion connector, put the cheapest dumbest Spartan 3 on it (100K gates = $10), soldering this should be fun ; I'll have the CPU load the bits into it on power-up. Writing the verilog code for this should be easy. I'll use the high speed serial out (SPI) from the CPU to feed it data.
> do you plan using uClinux or the linux distro that cames with the Atmel?
I hope so, yes.
But yeah, more when it arrives !
Yeah, the price is good, although with shipping and tax it should be 75$ = 120€.
> You have mentiond using FPGA for demuxing to multichannel. Well, how exactly do you plan doing that?
Well, stick a little board on the expansion connector, put the cheapest dumbest Spartan 3 on it (100K gates = $10), soldering this should be fun ; I'll have the CPU load the bits into it on power-up. Writing the verilog code for this should be easy. I'll use the high speed serial out (SPI) from the CPU to feed it data.
> do you plan using uClinux or the linux distro that cames with the Atmel?
I hope so, yes.
But yeah, more when it arrives !
Last time I ordered something from the US I ended up paying almost as much in shipping + taxes...
Yes, that's customs and import fees. They apply when you get it delivered by a business.
A solution is to ask a friend to carry it when traveling - or find a way of private shipping via a proxy.
A solution is to ask a friend to carry it when traveling - or find a way of private shipping via a proxy.
Hi Peufeu,
I don't want to confuse matters as you have already chosen the board but would these boxes do the job? http://www.dream-multimedia-tv.de/Bereiche/Produkte/
available from €100 - €300
I know these boxes are more geared towards digital video broadcasting but :
As they already have spdif output I'm wondering if I2S is also available off the board - can open one up to see what chip is used.
Other advantages:
- TV interface via scart - could be used for display of music title/navigation of music library
- Remote control
- some models can use internal disk up to 320GB for local music storage
- could also be used for cable/satellite TV or node on network?
- already built into attractive box with remote control & connection to display device built in
- can use wireless keyboard
What do you think? Does any of this make sense? Is it powerful enough?
John
I don't want to confuse matters as you have already chosen the board but would these boxes do the job? http://www.dream-multimedia-tv.de/Bereiche/Produkte/
available from €100 - €300
I know these boxes are more geared towards digital video broadcasting but :
As they already have spdif output I'm wondering if I2S is also available off the board - can open one up to see what chip is used.
Other advantages:
- TV interface via scart - could be used for display of music title/navigation of music library
- Remote control
- some models can use internal disk up to 320GB for local music storage
- could also be used for cable/satellite TV or node on network?
- already built into attractive box with remote control & connection to display device built in
- can use wireless keyboard
What do you think? Does any of this make sense? Is it powerful enough?
John
- Status
- Not open for further replies.