Pc -> Dac, How ?

[peufeu]

wakibaki :
If you really wanna do something useful build a well-documented open-source battery-driven reference source running from a generic CF or SD card with a TCXO clock.

Since such a device would be useless to me, I don't have any interest in building it....

soundcheck :
HDMI wasn't even put on peufeus list

Well, there is HDCP and encryption... it's easier to extract the signal from somewhere else (like, from the PC that plays the video).

Wavelength:
Basically if we go with the Cypress USB 2.0 controller, it would require some kind of FPGA to have complement I2S outputs. The flow is simple and would work pretty much like this:

USB2.0<===>Cypress[DATA]->FPGA---->I2S--->DAC(s).

The MCLK at the DAC would be fed into the FPGA and that would determine the rate and so forth. The Cypress would receive Endpoint 0 setup information as to the changes in the Fs rate and output those via GPIO ports. The GPIO output would go to the FPGA and also aid in the selection of MCLK's to support various Fs rates (i.e. 44.1, 48, 88.2, 96, 176.4, 192).

That's exactly what I'm doing
(plus FPGA oversampling etc).
Been doing the layout of the isolation module today...

jcarr:
Like how well a DAC is designed. If the given DAC shows a change in sound with a solid-state drive as opposed to a PC or optical-mechanical transport, I regard the design of the DAC as being lacking.

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 !

[Wavelength]

Peufeu,

Been doing the layout of the isolation module today...

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

[Russ White]

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

[Wavelength]

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

[Russ White]

Originally posted by Wavelength
Russ,


So Russ what are you testing with?

Thanks
Gordon

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

[Russ White]

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!

[Pjotr]

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.

[Wavelength]

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

[Russ White]

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

[phofman]

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.

Originally posted by soundcheck

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

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.