I have used it with my Buffalo DAC. Its very handy to do so because I only need bitclock, wordclock, and data. The ESS Sabre has an asynchronous I2S input.
I have not tried it with anything that needs a 256/128fs master clock.
Cheers!
Russ
I have not tried it with anything that needs a 256/128fs master clock.
Cheers!
Russ
Unfortunately the beagle board has its I2S bit clock generated via PLL from the 26MHz crystal. If there was an affordable miniPCI - PCI adapter available (IMO just a PCB layout with a cable), I would love to test an inexpensive low-power linux router with a quality PCI card with separate crystals for 44,1kHz/48kHz, placed in a shielded compartment away from the router board http://www.diyaudio.com/forums/showthread.php?postid=1667185#post1667185
phofman said:
With the DAC(ES9008) I am using this is not a problem in the least. 🙂
I can see how it might be with other DACs.
You actually can make the I2S output(clock) a slave. But it is not as simple. And I have no good reason to do it. 🙂
The really cool thing is I can tranfer stuff on to the SD card via USB, then listen to the thing headless. Well it is the head. 🙂
I can also play files via a USB hard drive.
I can also play files via a USB hard drive.
Some alternatives - potentially not really DIY - pretty much with multichannel in mind:
1. HDMI
HDMI wasn't even put on peufeus list. I think this needs to be considered.
8 channel LPCM. One of the few interfaces if not the only one able to cope with
the demands out there. Licensing might be an issue.
The Sabre is multichannel. The DAC board needs just a HDMI receiver. 😉
2. External PCIe solutions
E.G. Something like Magma via Expresscard. The external PCI card could be
powered by batteries. Magma is even working on a fibre connection.
3. Asus HDAV 1.3 deluxe
Can be full powered by battery. AFAIK 6 channel I2S can be taken of the connector
which connects the DAC daughter-board.
Cheers
1. HDMI
HDMI wasn't even put on peufeus list. I think this needs to be considered.
8 channel LPCM. One of the few interfaces if not the only one able to cope with
the demands out there. Licensing might be an issue.
The Sabre is multichannel. The DAC board needs just a HDMI receiver. 😉
2. External PCIe solutions
E.G. Something like Magma via Expresscard. The external PCI card could be
powered by batteries. Magma is even working on a fibre connection.
3. Asus HDAV 1.3 deluxe
Can be full powered by battery. AFAIK 6 channel I2S can be taken of the connector
which connects the DAC daughter-board.
Cheers
Soundcheck, all the presented solutions certainly bring quality sound, but none has the PLL-free crystal-provided clock for 44.1kHz-family audio. Currently I know just about some PCI cards and the asynchronous USB cards from E-MU, poorely supported in linux. Though I slowly start accepting that 44.1kHz audio is history now...
Hi Phofman,
(Maybe a bit OT but for reference)
I know of this one http://www.cambridgeaudio.com/summary.php?PID=320
It is available in the US for under $300. Have listened to it recently, sounds very good. I don’t know if it streams audio iso-synchronous or a-synchronous, it doesn’t need special drivers and works fine under Linux as well with Amarok. I couldn’t discriminate any difference in sound between S/PDIF (from my ZIOVA MC) and USB from PC.
Have compared it to the E-MU 0202. The Cambridge sounds slightly better IMO, but we are talking of differences of a few mm over a 10 m length then 😉
However it is 2 channel only.
(Maybe a bit OT but for reference)
I know of this one http://www.cambridgeaudio.com/summary.php?PID=320
It is available in the US for under $300. Have listened to it recently, sounds very good. I don’t know if it streams audio iso-synchronous or a-synchronous, it doesn’t need special drivers and works fine under Linux as well with Amarok. I couldn’t discriminate any difference in sound between S/PDIF (from my ZIOVA MC) and USB from PC.
Have compared it to the E-MU 0202. The Cambridge sounds slightly better IMO, but we are talking of differences of a few mm over a 10 m length then 😉
However it is 2 channel only.
phofman said:
How about your ideas? 😉
I think you're looking for an Altmann DAC, the only DAC (maybe also Empirical reclocker?!?!?) I know with switchable PLL-free crystals. But since Sabre there doesn't seem to be a need for it any longer.
When it comes to poor support of EMU, Alsa is still looking for somebody taking care
on the driver. 😉 Skilled people shouldn't waste their time in these kind of forums. 😀
As you might know EMU opened up the MAC drivers to the public.
Cheers
Russ White said:
Russ,
Actually phofman is correct. It may not seem so but there is allot of jitter generated by the PLL and this will cause a problem before it even get's to the ESS.
For many years it was thought that upsamplers and reclockers could fix jitter already induced into the system. But now we know allot more about jitter and how it effects devices.
For instance, Benchmark and BelCanto both make very good products and say that their upsamplers remove the variable of jitter induced into the system because of thier implementation. If this was correct then any input would merly have the same jitter as seen by the output as the intrinsic jitter of the dac itself and nothing else. But in tests both of these products had significantly higher jitter under USB than their SPDIF counterparts. There was even variations in the output jitter with different inputs on their SPDIF ports.
You can search these finding on Stereophile. Do note the BelCanto 24 bit JTEST was thrown out as the device was 16 bit only USB at the time and the downsampling would have killed the JTEST data before it reached the dac. BelCanto now is using the Centrance code like the Benchmark, Empirical and PS Audio.
To futher prove this I have been working with some of the magazines and Charlie Hansend and the rest of the guys at Ayre. I bought a Wavecrest DTS jitter analyzer. This is the unit that any oscillator company in the world uses to measure jitter. You can basically measure jitter on any oscillator including the Bit Clock (SCLK), Master Clock (MCLK) and Word Clock (WCLK). We tested all the SPDIF ports of several dacs using the Prism dScope as the source which has an extremly low output jitter. We also used MAC's, Linux x86 and Vista and XP to stream data USB. We then took measurements at the output of the SPDIF receiver and the input to the DAC. The results were eye opening... but truely did result in the understanding that yes the implementation of the interface into an upsampler, reclocker and such has a HUGE effect on the resulting jitter of the system.
Therefore we can conclude that the damage was done BEFORE it reached the upsampler in the same way it would with your setup on the ESS.
Now remember jitter is based on clocked audio output. So Peufeu's concept of using the Cypress part which outputs data (non jitter induced) into an FPGA and deriving the I2S output as a function of the dac's MCLK will result in better preformance.
This is why when looking for suitable USB 24/192 devices you must look for ones that have the capability to run what is called Master Clock IN (MCLKin). This is how I use the TAS1020B USB Audio controller in async mode on my products.
Very few devices have this kind of capability. Running say MCLK into a MCU as the system clock will only saturate that clock with phase noise which will result in more jitter. It has to have some way of getting a clean low jitter clock into the section that converts DATA in bytes, words what ever into I2S. That is the true key here...
So far the new Atmel AVR32 is the only complete chip capable of this. The Cyan eCog is but it's I2S output is interrupt driven and may cause problems at 24/192.
Thanks
Gordon
Since such a device would be useless to me, I don't have any interest in building it....
Well, there is HDCP and encryption... it's easier to extract the signal from somewhere else (like, from the PC that plays the video).
That's exactly what I'm doing 😉
(plus FPGA oversampling etc).
Been doing the layout of the isolation module today...
I completely agree with this.
Now, yes I'd like to build a community, but first I need to get something running. We're on the hardware now, it should still take some time but it's coming closer.
Happy new year folks !
Peufeu,
Remember to have some real good termination networks on the outputs of these. These things overshoot like the cows coming home. All that will result in ground imbalance which causes the receiving chip to have ground noise which is not a good idea for anything.
A simple resistor and then resistor/cap to ground at the input should suffice.
Thanks
Gordon
Remember to have some real good termination networks on the outputs of these. These things overshoot like the cows coming home. All that will result in ground imbalance which causes the receiving chip to have ground noise which is not a good idea for anything.
A simple resistor and then resistor/cap to ground at the input should suffice.
Thanks
Gordon
Gordon, I am sorry, but your assessment is just simply incorrect. I have actually had measured jitter sidebands of the DAC with this source (and others) when I first undertook this little project which was months ago.
The asynchronous input of the ES9008 (and especially the new Sabre32) is not at all the same as a SRC4192 or equivalent. It is significantly different. You cannot compare them. They do not work the same way. This is why ESS took out a patent. 🙂
You are drastically oversimplifying things by lumping the ESS DAC in with other DACs and approaches to tweaking those DACs.
I have been talking with Dustin about this at length. 🙂
I will publish technical specification including measurements when we release our consumer DAC. Which will be soon. So far its shaping up very well.
Your comparison with any other DAC and techniques used to tweak them is really not going to yield the same sort of result as your expecting. I am not just throwing ideas out there. I have a working practical example which can and has been measured. 🙂
You don't need asynchronous USB to get the best out of the ESS chip. Sorry. 🙂
Cheers!
Russ
The asynchronous input of the ES9008 (and especially the new Sabre32) is not at all the same as a SRC4192 or equivalent. It is significantly different. You cannot compare them. They do not work the same way. This is why ESS took out a patent. 🙂
You are drastically oversimplifying things by lumping the ESS DAC in with other DACs and approaches to tweaking those DACs.
I have been talking with Dustin about this at length. 🙂
I will publish technical specification including measurements when we release our consumer DAC. Which will be soon. So far its shaping up very well.
Your comparison with any other DAC and techniques used to tweak them is really not going to yield the same sort of result as your expecting. I am not just throwing ideas out there. I have a working practical example which can and has been measured. 🙂
You don't need asynchronous USB to get the best out of the ESS chip. Sorry. 🙂
Cheers!
Russ
Russ,
Since I have the ESS here and working and obviously other dacs with other interfaces and allot of test gear, I can say that the results are true.
While the ESS does a good job of getting rid of the jitter it cannot fix things that happen before it, just as these other dacs.
Maybe an easier way to see this is this way. When we test for side bands we are testing the system, not the chip. Therefore we inject a signal into the system and test the resulting output. The accumulated jitter of the system is seen in the resultant output.
While most modern day dac chips do have a bit of jitter reduction ANYTHING that is done before or around these chips will help in the resultant output.
I am getting less than 55ps of jitter from the ESS. That's damn good for any dac, especially a USB unit.
So Russ what are you testing with?
Thanks
Gordon
Since I have the ESS here and working and obviously other dacs with other interfaces and allot of test gear, I can say that the results are true.
While the ESS does a good job of getting rid of the jitter it cannot fix things that happen before it, just as these other dacs.
Maybe an easier way to see this is this way. When we test for side bands we are testing the system, not the chip. Therefore we inject a signal into the system and test the resulting output. The accumulated jitter of the system is seen in the resultant output.
While most modern day dac chips do have a bit of jitter reduction ANYTHING that is done before or around these chips will help in the resultant output.
I am getting less than 55ps of jitter from the ESS. That's damn good for any dac, especially a USB unit.
So Russ what are you testing with?
Thanks
Gordon
Wavelength said:
Gordon,
Thanks for you concern. But I have a pretty firm grasp of the process.
I am testing some things at home with my MSO9212. When I need more precision I take to the UT physics lab where I have access to much better gear.
For final testing I send the DAC off (I will not disclose where yet), as no one should trust too heavily measurements performed by the vendor. 🙂
Who has measured your stuff? Well beside you?
I am sorry, but your arguments still do not reflect the reality I am seeing.
Cheers!
Russ
I only commented on the Beagle because its an extremely effective solution if you use the ESS DAC. And it's quite cheap. I actually don't have any plans to use it in a commercial application. It was just a personal experiment. It is a lot of fun to play with!
You can slave the I2S clocks to whatever ultra low jitter clock you like if it makes you feel better. 🙂
It's not as easy to slave the clocks, but its not that hard either.
In practice I found it to perform extremely well out of the box.
I only meant to encourage those who are willing to pursue things without paralysis by analysis. 🙂
Go for it, it will work, and very well!
You can slave the I2S clocks to whatever ultra low jitter clock you like if it makes you feel better. 🙂
It's not as easy to slave the clocks, but its not that hard either.
In practice I found it to perform extremely well out of the box.
I only meant to encourage those who are willing to pursue things without paralysis by analysis. 🙂
Go for it, it will work, and very well!
Hmm, let’s face what clock jitter actually does: At the analogue output of a dac chip it manifest itself as noise. If this noise was purely white there is nothing to worry about. But unfortunately is not purely white, it has signal correlated spurs and source (PC) correlated spurs.
Two approaches are mainly used to circumvent it.
1/ Use an ultra low noise x-tal clock, clocking the DAC-chip directly and slave everything else to it up to the source in the PC
2/ De-correlate the spurs as much as possible. In other words make the noise caused by jitter as white as you can.. This is what all the resamplers do, either one in his own manner.
What is the best track to go? I really wouldn’t know. Both approaches can give very good sound in the end. IMHO the quality and accuracy of the digital filter has more impact than HOW you remove/de-correlate jitter spurs.
Two approaches are mainly used to circumvent it.
1/ Use an ultra low noise x-tal clock, clocking the DAC-chip directly and slave everything else to it up to the source in the PC
2/ De-correlate the spurs as much as possible. In other words make the noise caused by jitter as white as you can.. This is what all the resamplers do, either one in his own manner.
What is the best track to go? I really wouldn’t know. Both approaches can give very good sound in the end. IMHO the quality and accuracy of the digital filter has more impact than HOW you remove/de-correlate jitter spurs.
Russ,
First understand that I am not attacking you. I was actually one of the people who lobbied for you to stick around on DIYHIFI.org. I did think it was a little silly using an alias and writing in third person. I think what you did with the ESS part (and I have said this on several websites) is commendable. This allowed the DIY community and I am sure several commercial companies to look at the capabilities of this dac.
But this is not the thread to talk about ESS or other dacs this is computer audio and how to get data out of there an into here.
What I said will make perfect sense to anyone who read it. This is the basis for any engineer project.
As Charlie Hansen always says There is no free lunch.
What I am saying is there is no magic bullet that removes jitter. Anyone can see on the Stereophile website that what I am saying is true.
There are tons of reviews of my products on the web and print. There are several more coming down the pike.
~~~~~~~~~
There are tons of Linux boards like the Beagle out there. Most of them again suffer from the same problem. Using a noisey PLL to derive audio clocks is no good for the end product. There are also boards like this using the Atmel, ST, Marvell and other ARM based processors that will work equally well.
Just not great and I think that is what the intention from Peufeu was.
Thanks
Gordon
First understand that I am not attacking you. I was actually one of the people who lobbied for you to stick around on DIYHIFI.org. I did think it was a little silly using an alias and writing in third person. I think what you did with the ESS part (and I have said this on several websites) is commendable. This allowed the DIY community and I am sure several commercial companies to look at the capabilities of this dac.
But this is not the thread to talk about ESS or other dacs this is computer audio and how to get data out of there an into here.
What I said will make perfect sense to anyone who read it. This is the basis for any engineer project.
As Charlie Hansen always says There is no free lunch.
What I am saying is there is no magic bullet that removes jitter. Anyone can see on the Stereophile website that what I am saying is true.
There are tons of reviews of my products on the web and print. There are several more coming down the pike.
~~~~~~~~~
There are tons of Linux boards like the Beagle out there. Most of them again suffer from the same problem. Using a noisey PLL to derive audio clocks is no good for the end product. There are also boards like this using the Atmel, ST, Marvell and other ARM based processors that will work equally well.
Just not great and I think that is what the intention from Peufeu was.
Thanks
Gordon
Gordon,
I honestly couldn't care less about the malcontents at DIYHiFi. What goes on there speaks for itself. I do appreciate your support though, and give you credit for that.
I was only answering the post asking if anyone had used the "Beagle". I did. And it sounds great, when used with the ESS Sabre.
Now if you were to use it into a lesser DAC it probably would not sound so good especially if you tried to get the master clock from the Beagle.
I am sure you have done some interesting research. If I have time I will read it. But I have some very interesting test results too. 🙂
Right now I have to test my Sabre32. 😀 This thing is sweeeeet.
Cheers!
Russ
I honestly couldn't care less about the malcontents at DIYHiFi. What goes on there speaks for itself. I do appreciate your support though, and give you credit for that.
I was only answering the post asking if anyone had used the "Beagle". I did. And it sounds great, when used with the ESS Sabre.
Now if you were to use it into a lesser DAC it probably would not sound so good especially if you tried to get the master clock from the Beagle.
I am sure you have done some interesting research. If I have time I will read it. But I have some very interesting test results too. 🙂
Right now I have to test my Sabre32. 😀 This thing is sweeeeet.
Cheers!
Russ
My suggestion about a linux router with a miniPCI - PCI adapter was meant as an (untested yet) ordinary-man alternative to the FPGA-magic ethernet DAC of peufeu which is way above most people's capabilities. The idea is low computing power means low power consumption and thus less EMI/RFI; the PCI card can be placed in a shielded place; the interconnect cable allows supplying the PCI card with a separate clean power supply; perhaps some ground connection wizardry could be applied.
I guess any miniPCI-equipped router should be powerful enough for 8 channel 192/24 wav ethernet playback (netcat?) with a reasonably long DMA buffer/latency (i.e. tens of IRQs per second max). If I could get hold of a reasonably priced miniPCI - PCI adapter I would happily purchase the router to test the concept.
I do not have the card on hand, and the magic Takashi conjured with XFi was unprecedented (and a very unproductive way of driver development too ). However, a sample of a recently released ice1724-based card yet unsupported in alsa is already on the way. I am negotiating NDA terms for the documentation with the card's manufacturer now.
I guess any miniPCI-equipped router should be powerful enough for 8 channel 192/24 wav ethernet playback (netcat?) with a reasonably long DMA buffer/latency (i.e. tens of IRQs per second max). If I could get hold of a reasonably priced miniPCI - PCI adapter I would happily purchase the router to test the concept.
soundcheck said:
I do not have the card on hand, and the magic Takashi conjured with XFi was unprecedented (and a very unproductive way of driver development too ). However, a sample of a recently released ice1724-based card yet unsupported in alsa is already on the way. I am negotiating NDA terms for the documentation with the card's manufacturer now.
- Status
- Not open for further replies.