Let's stop polluting the ESS thread, shall we ?
OK so :
- CD is dead
- DVD is dead
- SACD is dead
- Physical formats are dead anyway
This settled, and it being pretty obvious that FLAC stored on RAID backed up twice will outlast the original CDs by a few centuries, while being more convenient, and cheaper, let's get to how to make it also sound better.
So how to connect some high quality DACs to a PC ?
(or a Mac, let's not be religious, it's the same hardware anyway)
We're aiming for high quality, so no time to lose with known-bad solutions, like :
- Clock recovered from anything except maybe a VCCXO and then only if Guido Tent blesses it
- ASRC
- Master clock not in DAC
- Digital volume control
- etc
Also it should support multichannel 24-192 because, why build something that is already obsolete ? I wouldn't consider digitizing my vinyls at 16 bits, thank you.
So, in order to implement this :
We can do :
- Slaved soundcard
- FireWire
- Ethernet
- Asynchronous/bulk USB
Slaved soundcard is pretty easy, master clock in DAC, encode it as SPDIF, send to soundcard, soundcard sends SPDIF back, decode, play. However it is a bit clumsy, since how do you switch sample rates ? use replaygain ? you don't...
FireWire.
Apart from the fact that FireWire is dead, it's nice... OK, it needs a powerful CPU in the device like an ARM7, and a few tens of thousands of lines of code of firmware, and it's immature technology, and you'll need 6 months to make it work, but it's cool, it's Apple after all.
Bottom Line : USB is cheaper and this is what matters. If you need to put an ARM7 @ 50 MHz in your peripheral to do what a 8051 could do if you used USB, you gotta have a really good justification for it, because you're getting fired by the bean counters. That is what is killing FW. Yes, FW is a better protocol. Does it do the so much better that it can add $100-$200 to the end product price ? Hm...
The DICE is nice but you need to sign a NDA, it's expensive, needs a 4 layer board, the firmware is complex, etc, etc.
Ethernet.
Ethernet is nice. I used Ethernet to stream audio data to a little FPGA board. however Ethernet has two drawbacks :
- It needs a powerful CPU in the device
- It has rather high and random latency
Needing a powerful CPU in the device is bad, because in order to implement custom oversampling filters, digital active crossover, multichannel, etc, you really need a FPGA, and there are no off the shelf boards on the market which combine Ethernet + A good CPU + a good FPGA + cheap.
Also a $50 Intel Atom mini-itx mobo with a USB DAC, linux and netjack will do ethernet audio streaming for cheaper than anything, and it will decode your divx, and it will have a 19" LCD for Amarok.
Someone posted the Ethernut link... OK, it's nice. Is it better and/or cheaper than a $50 intel atom mini-itx board ? No, and no. OK, you could use it for stereo 44.1k...
USB
USB is nice because it is simple. A $100 Nexys board from Digilent, some firmware, some verilog, and you get 45 MBytes/s of streaming data. I have yet to implement the DSP chain and then connect a DAC to it. This should follow shortly. I will be using bulk mode, so the clock is in the DAC. I have a working Python driver which can stream data and access device registers over USB.
Bottomline : it was much easier than Ethernet (which I did) and FireWire (which I dropped) and harder than slaving a soundcard, but so much better.
Of course a custom linux kernel ALSA driver will need to be implemented. Someone will probably do it... that might or might not be me... it's nor very hard. All testing can be done using a userspace driver written in Python. Easy.
When it's done (!) it will be opensource so you can try it.
OK so :
- CD is dead
- DVD is dead
- SACD is dead
- Physical formats are dead anyway
This settled, and it being pretty obvious that FLAC stored on RAID backed up twice will outlast the original CDs by a few centuries, while being more convenient, and cheaper, let's get to how to make it also sound better.
So how to connect some high quality DACs to a PC ?
(or a Mac, let's not be religious, it's the same hardware anyway)
We're aiming for high quality, so no time to lose with known-bad solutions, like :
- Clock recovered from anything except maybe a VCCXO and then only if Guido Tent blesses it
- ASRC
- Master clock not in DAC
- Digital volume control
- etc
Also it should support multichannel 24-192 because, why build something that is already obsolete ? I wouldn't consider digitizing my vinyls at 16 bits, thank you.
So, in order to implement this :
An externally hosted image should be here but it was not working when we last tested it.
We can do :
- Slaved soundcard
- FireWire
- Ethernet
- Asynchronous/bulk USB
Slaved soundcard is pretty easy, master clock in DAC, encode it as SPDIF, send to soundcard, soundcard sends SPDIF back, decode, play. However it is a bit clumsy, since how do you switch sample rates ? use replaygain ? you don't...
FireWire.
Apart from the fact that FireWire is dead, it's nice... OK, it needs a powerful CPU in the device like an ARM7, and a few tens of thousands of lines of code of firmware, and it's immature technology, and you'll need 6 months to make it work, but it's cool, it's Apple after all.
Bottom Line : USB is cheaper and this is what matters. If you need to put an ARM7 @ 50 MHz in your peripheral to do what a 8051 could do if you used USB, you gotta have a really good justification for it, because you're getting fired by the bean counters. That is what is killing FW. Yes, FW is a better protocol. Does it do the so much better that it can add $100-$200 to the end product price ? Hm...
The DICE is nice but you need to sign a NDA, it's expensive, needs a 4 layer board, the firmware is complex, etc, etc.
Ethernet.
Ethernet is nice. I used Ethernet to stream audio data to a little FPGA board. however Ethernet has two drawbacks :
- It needs a powerful CPU in the device
- It has rather high and random latency
Needing a powerful CPU in the device is bad, because in order to implement custom oversampling filters, digital active crossover, multichannel, etc, you really need a FPGA, and there are no off the shelf boards on the market which combine Ethernet + A good CPU + a good FPGA + cheap.
Also a $50 Intel Atom mini-itx mobo with a USB DAC, linux and netjack will do ethernet audio streaming for cheaper than anything, and it will decode your divx, and it will have a 19" LCD for Amarok.
Someone posted the Ethernut link... OK, it's nice. Is it better and/or cheaper than a $50 intel atom mini-itx board ? No, and no. OK, you could use it for stereo 44.1k...
USB
USB is nice because it is simple. A $100 Nexys board from Digilent, some firmware, some verilog, and you get 45 MBytes/s of streaming data. I have yet to implement the DSP chain and then connect a DAC to it. This should follow shortly. I will be using bulk mode, so the clock is in the DAC. I have a working Python driver which can stream data and access device registers over USB.
Bottomline : it was much easier than Ethernet (which I did) and FireWire (which I dropped) and harder than slaving a soundcard, but so much better.
Of course a custom linux kernel ALSA driver will need to be implemented. Someone will probably do it... that might or might not be me... it's nor very hard. All testing can be done using a userspace driver written in Python. Easy.
When it's done (!) it will be opensource so you can try it.
I'm just starting to play around with the AD Blackfin and Sharc DSP's. Blackfin is interesting option as in input device. The Blackfin has an onboard MAC and requires an external PHY. Blackfin also supports USB.
The thinking is to leverage a Blackfin running ucLinux, which is already supported, to connect to ethernet and process and decode the packets onto the I2S outputs. The blackfin could also control DAC chips control pins as needed. Of course spdif and TOS could be added as an option if desired with little effort.
I'm also looking at the Blackfin driving the SHARC for room correction, digital crossover, etc.
-David
The thinking is to leverage a Blackfin running ucLinux, which is already supported, to connect to ethernet and process and decode the packets onto the I2S outputs. The blackfin could also control DAC chips control pins as needed. Of course spdif and TOS could be added as an option if desired with little effort.
I'm also looking at the Blackfin driving the SHARC for room correction, digital crossover, etc.
-David
Peufeu , exactly why an ASRC is considered bad? Esp, since the best measuring audio dac ever has it right inside the package.
Also, you seem to forgot that the TI / BB chips have direct downsampling option, the data is not harmed by downsampling filter that way. This is a very diy friendly solution in fact. One downside is that once you want to pass it 192khz (precise "whatever-phase" SRC computed inside PC) with direct ds engaged, you have to use uncommon clock freq to make it pass 200ish khz, therefore the computers soundcard can not be slaved to it, but again , I can sync to my ADC-s clock then, who cares?
One thing I could use is a multichannel co-phase sampled ASRC thats not limited to 210ish khz max output freq, and can do agresive dithering above 100khz.
Telstar, DW80xxx , you seem to prefer vaporware as far i see
Also, you seem to forgot that the TI / BB chips have direct downsampling option, the data is not harmed by downsampling filter that way. This is a very diy friendly solution in fact. One downside is that once you want to pass it 192khz (precise "whatever-phase" SRC computed inside PC) with direct ds engaged, you have to use uncommon clock freq to make it pass 200ish khz, therefore the computers soundcard can not be slaved to it, but again , I can sync to my ADC-s clock then, who cares?
One thing I could use is a multichannel co-phase sampled ASRC thats not limited to 210ish khz max output freq, and can do agresive dithering above 100khz.
Telstar, DW80xxx , you seem to prefer vaporware as far i see
Russ White said:
It's a glass optical standard introduced long ago by AT&T and used on a few transports-dacs combo in the past (i.e. audio synthesis dax, muse) and IMO still unsurpassed.
http://en.wikipedia.org/wiki/File:ST_connector.jpg
Gang,
I agree, Firewire is dead... Apple introduced it and they are taking it away. The problem is they moved too slowly and they lost.
Peufeu forgot too mention that USB requires 2.0 as high speed would be required for 24/192. OSX is the only OS supporting Audio Class 2.0 drivers. Windows and Linux do not support them.
Though EMU has posted it's source code for the 0202/0404 for OSX up on sourceforge and this code could easily be adapted for linux since OSX is really a unix based system.
Or you could do a Bulk Mode USB DAC.
Thanks
Gordon
I agree, Firewire is dead... Apple introduced it and they are taking it away. The problem is they moved too slowly and they lost.
Peufeu forgot too mention that USB requires 2.0 as high speed would be required for 24/192. OSX is the only OS supporting Audio Class 2.0 drivers. Windows and Linux do not support them.
Though EMU has posted it's source code for the 0202/0404 for OSX up on sourceforge and this code could easily be adapted for linux since OSX is really a unix based system.
Or you could do a Bulk Mode USB DAC.
Thanks
Gordon
Point taken.peufeu said:
The other thing that worries me in general is the overall software. One of the reasons I like my current setup (MaxtorII with FireflyMediaServer running on it talking to my ethernet having Rokus in different rooms talking to good outboard DACs) is the software. Browsing, the database management, playlists, etc. etc. Plus I like the fact that I don't have to have a computer running all the time (meaning: no keyboard, no monitor, and certainly not huge electricity suck; though this is changing). Just a web interface for occasional maintenance (low at that!). Each device does only one thing and does it really well. (I know, the Roku will only do 44.1kHz, so I gotta find something better.) Just having all the programming to run a decent VFD display like they have on the Roku... Yeay, it's doable, but who will do it at a professional level?
That would be some of my concerns regarding a device that fits what I am looking for. (Different folks want different strokes.)
peter
Damn, I didn't want to get involved...
ST appears to be a single channel, so it either has several carriers for the individual channels required (at least clock, data, ws) which would need to be demodulated, or it is multiplexed digital data which is probably self clocking, which will need demultiplexing.
Either scenario can't be ideal and will introduce jitter, unlike I2S.
I think you'd be better off using I2S over RS423 or LVDS.
ST appears to be a single channel, so it either has several carriers for the individual channels required (at least clock, data, ws) which would need to be demodulated, or it is multiplexed digital data which is probably self clocking, which will need demultiplexing.
Either scenario can't be ideal and will introduce jitter, unlike I2S.
I think you'd be better off using I2S over RS423 or LVDS.
peufeu said:
Right whaddawegot here.
A DAC. And a clock. Wired or? Taking the result thru an inverter, a resistor (and something that looks like it might be the PSTN) and feeding it to a PC. Wut?
Not only do we got textual drivel, we got graphical drivel too.
You MIGHT have something useful or interesting to say, but you're doing a pretty good job of hiding it.
w
Yep...
philpoole said:
audio synthesis used two ST channels:
http://www.audiosynthesis.co.uk/dax_discrete5.htm
Anyway, i dont think i2s is a bad interface, if implemented well.
Re: Re: Pc -> Dac, How ?
Sharc & Blackfin are excellent products. Blackfin is a bit underpowered for audio though (if you want high precision, it gets slow). However it will be powerful enough for what you want to do. You could run Linux on it, and simply install net-jack, to make a remote soundcard. I considered this, it is an elegant solution, but in the end I preferred USB, because adding a $50 Atom mini-PC will turn it into an Ethernet DAC (with a big LCD to display Amarok...)
ASRC... why would you use it when you can get rid of jitter by slaving the source ?... Basically the way the ESS Sabre does it is good (ASRC while oversampling massively), but the way the standard ASRC chips do it, between two closely related frequencies, is extremely complex, too complex for a cheap chip like this... which is why they sound better when using some unrelated clocks. Better no ASRC at all.
Actually, yeah. Do we have mobos with some 24-192 signals ? Probably not I²S though, not a problem, solder a few wires, add isolators and FPGA to convert format, add master clock... doable with a $50 FPGA board from Digilent and a bunch of wires... IF THE THING HAS A CLOCK INPUT. Who wants to check this ?
Yeah, Apple... They are good, but sometimes... argh.
Anyway yes, USB 2.0. The FX2LP chip maxes out the USB 2 bandwidth (tested : 45 MB/s) provided whatever you put after it is fast enough.
There is USB Audio Device Class V2 which is a driver model that allows clock-in-dac schemes, which is what I need. Unfortunately it is a bit early (Mac only as you say). So, when it's ready, I'll probably update the firmware in my chip to make it look like a standard device (but clock master). In the meantime, a custom bulk driver should be good. Those are not mutually exclusive btw.
Exactly, I don't like recreating stuff that already exists... a SILENT small PC with Amarok and a 15" LCD beats any 3" LCD for the user-friendliness, and it can also play movies and run BruteFIR...
Ah, rfbrw, always so cheerful
no topic would be complete without your snide remarks.
Look at CD sales, look at SACD sales, look at pirate downloads, it is not the audiophiles that are making the market, it is the mass, and the mass wants MP3 without DRM to play on their cellphones, and the mass wants playlists and reasonable sound quality on their super plastic (TM) home theater. Fortunately I see emerging labels which start to offer FLAC @ 24-96 or 24-192 for a reasonable price... this is the future !
LOL.
Obviously,
- the part of the drawing that you removed meant that you can place the clock in a noisy place, then run it through a big bunch of stuff, then waste your time cleaning it (or not)
- and the part that you quoted means that if you put the clock close to the DAC, and send a buffered copy to the source, the problem goes away as long as the digital transmission is error-free.
True, but it only matters if the clock you transmit to it will be used for DAC. If it is only a data transport, it is good.
Well, you drew the bulk USB protocol... simple isn't it ? The FX2 and the PC chipset do all this in hardware.
Several ways to do this :
- Use a small buffer in the DAC (like, 32-64 kB) then the PC always sends data. When the buffer is full, automatic USB bulk flow control takes care of things like ACKs, error checking, retransmission... FX2LP does all this in hardware, you just have to set AUTOOUT=1
- If you have an ADC, and I will, you can do it different : the PC waits to receive a block of ADC samples, then it sends back to the device as many DAC samples. So, it is always playing as many samples as it is recording. Preload the buffer on startup with a number of samples corresponding to your desired latency.
I'll use the second method because it is usable with isochronous asynchronous and also bulk, and you don't need to change the FIFO sizes, just decide how much stuff you put in them at the beginning.
dw8083 said:
Sharc & Blackfin are excellent products. Blackfin is a bit underpowered for audio though (if you want high precision, it gets slow). However it will be powerful enough for what you want to do. You could run Linux on it, and simply install net-jack, to make a remote soundcard. I considered this, it is an elegant solution, but in the end I preferred USB, because adding a $50 Atom mini-PC will turn it into an Ethernet DAC (with a big LCD to display Amarok...)
tritosine said:
ASRC... why would you use it when you can get rid of jitter by slaving the source ?... Basically the way the ESS Sabre does it is good (ASRC while oversampling massively), but the way the standard ASRC chips do it, between two closely related frequencies, is extremely complex, too complex for a cheap chip like this... which is why they sound better when using some unrelated clocks. Better no ASRC at all.
Russ White said:
Actually, yeah. Do we have mobos with some 24-192 signals ? Probably not I²S though, not a problem, solder a few wires, add isolators and FPGA to convert format, add master clock... doable with a $50 FPGA board from Digilent and a bunch of wires... IF THE THING HAS A CLOCK INPUT. Who wants to check this ?
Wavelength said:
Yeah, Apple... They are good, but sometimes... argh.
Anyway yes, USB 2.0. The FX2LP chip maxes out the USB 2 bandwidth (tested : 45 MB/s) provided whatever you put after it is fast enough.
There is USB Audio Device Class V2 which is a driver model that allows clock-in-dac schemes, which is what I need. Unfortunately it is a bit early (Mac only as you say). So, when it's ready, I'll probably update the firmware in my chip to make it look like a standard device (but clock master). In the meantime, a custom bulk driver should be good. Those are not mutually exclusive btw.
schro20 said:
Exactly, I don't like recreating stuff that already exists... a SILENT small PC with Amarok and a 15" LCD beats any 3" LCD for the user-friendliness, and it can also play movies and run BruteFIR...
rfbrw said:
Ah, rfbrw, always so cheerful
no topic would be complete without your snide remarks.Look at CD sales, look at SACD sales, look at pirate downloads, it is not the audiophiles that are making the market, it is the mass, and the mass wants MP3 without DRM to play on their cellphones, and the mass wants playlists and reasonable sound quality on their super plastic (TM) home theater. Fortunately I see emerging labels which start to offer FLAC @ 24-96 or 24-192 for a reasonable price... this is the future !
wakibaki said:
LOL.
Obviously,
- the part of the drawing that you removed meant that you can place the clock in a noisy place, then run it through a big bunch of stuff, then waste your time cleaning it (or not)
- and the part that you quoted means that if you put the clock close to the DAC, and send a buffered copy to the source, the problem goes away as long as the digital transmission is error-free.
Cauhtemoc said:
True, but it only matters if the clock you transmit to it will be used for DAC. If it is only a data transport, it is good.
marziom said:
Well, you drew the bulk USB protocol... simple isn't it ? The FX2 and the PC chipset do all this in hardware.
Several ways to do this :
- Use a small buffer in the DAC (like, 32-64 kB) then the PC always sends data. When the buffer is full, automatic USB bulk flow control takes care of things like ACKs, error checking, retransmission... FX2LP does all this in hardware, you just have to set AUTOOUT=1
- If you have an ADC, and I will, you can do it different : the PC waits to receive a block of ADC samples, then it sends back to the device as many DAC samples. So, it is always playing as many samples as it is recording. Preload the buffer on startup with a number of samples corresponding to your desired latency.
I'll use the second method because it is usable with isochronous asynchronous and also bulk, and you don't need to change the FIFO sizes, just decide how much stuff you put in them at the beginning.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.