[audioengr]

Quote:

Originally Posted by Soundproof /img/forum/go_quote.gif I trust you read on, since it was a rhetorical question, with the answer supplied by Stereophile and John Atkinson, in the excerpt I posted from the magazine!

I dont believe everything I read in Stereophile.

Steve N.

 

[audioengr]

Quote:

Originally Posted by Wavelength /img/forum/go_quote.gif Actually the PCM2705 uses a 12MHZ crystal or clock and multiplies it to 96MHZ see the figure on page 7. The SpAct Audio Clock Recovery I would have to agree is pretty bad in the jitter department. I found that this chip and the other PCM27xx series chips seems to suffer from the jitter which is caused by the SigmaDelta dac and output. They seem to effect the power supply and master clock (noise wise) which in turn causes more problems. The problem is there is no way to really turn this off.

I stand corrected. I knew that. I was thinking of the TAS1020. The PCM270X uses a 12MHz clock.

STeve N.

 

[Wavelength]

Steve,

Quote:

No, the data was converted from USB to S/PDIF and then S/PDIF back to USB. Bit identical. It was done jointly by the developers and Benchmark engineers. I would not have paid a small fortune to license it if it wasn't. The boys that developed this are a clever lot. Took them over 2 years to do it. Steve N.

That's what the refence code does, there nothing big about that. I mean the tas1020 cannot manipulate data. So basically what it receives is what it sends out, no big deal.

Now the reason for the Centrance code sounds better than your MAudio code is simple. The MAudio code is setup for 24 bit adc and dac. The TAS1020 does not really have the buffer space to pull that off well. But if you dedicate the entire 1500 bytes to the dac portion then it can some really trick stuff.

The bigger step would be Async mode and I think Centrance is selling that also. Heck I have about 900 hours of programming, $2500 for the compiler, $2500 for the emulator... heck Steve you proabably got a pretty good deal.

The big point that Centrance makes that is not correct is that they did something fancy so the os would not resample. Common... there is no enumeration that is going to do that. The os is always going to do what ever it wants before it's sent out.

An easy test would be use XP with the kmixer and send it out media player. Really the only way to make sure the kmixer does not resample is do what I do. Only allow 44.1K then what's it going to do? As soon as you offer other rates there is really nothing that is going to stop it.

Thanks
Gordon

 

[audioengr]

Quote:

Originally Posted by Wavelength /img/forum/go_quote.gif Steve, That's what the refence code does, there nothing big about that. I mean the tas1020 cannot manipulate data. So basically what it receives is what it sends out, no big deal.

No, the raw .wav data in the computer memory was transmitted out over USB and then read back using another device using USB and stored in memory again. Then the read-back data was compared to the orginal .wav file. They were identical. This is the whole enchilada, Windows driver, kmixer, firmware, hardware.

STeve N.

 

[maarek99]

Quote:

Originally Posted by Wavelength /img/forum/go_quote.gif We can only deal with the data that is given to us and that is almost never bit perfect.

Rubbish. There is nothing mystical about doing bitperfect.

 

[vapman]

FLAC (foobar2000) -> AV710 -> NAD 3155 -> SR-60/K301

Sounds excellent. I was doing AV710 straight out to SR-60 for a while but this sounds so much better.

 

[Wavelength]

Quote:

Originally Posted by maarek99 /img/forum/go_quote.gif Rubbish. There is nothing mystical about doing bitperfect.

Maarek,

I am not saying there is. What I am saying is that there is no magic USB enumeration that will mystify the KMIXER from delivering bit perfect data and this is the claim they are making.

Anything you get from the drivers for sure will be intack. Doing testing like:

Quote:

No, the data was converted from USB to S/PDIF and then S/PDIF back to USB. Bit identical. It was done jointly by the developers and Benchmark engineers. I would not have paid a small fortune to license it if it wasn't. The boys that developed this are a clever lot. Took them over 2 years to do it.

Big deal... I hope it would be bit perfect. Well of course you could have communications errors in SPDIF or a slipped sample in USB as they do not offer error recovery.

But you cannot expect bit perfect data when going through the KMIXER. There is no magic bullet for that.

Thanks
Gordon

 

[TheVinylRipper]

OK, I'm gonna dip my toe in this water..

I've been ripping vinyl for a while now, for a long time I was using a Turtle Beach Santa Cruz which has 18 bit ADC's and 20 bit DAC's.

When I look at the waveforms on the screen, the ticks, clicks and pops stand out vividly, particularly when I use spectral display mode.

The rise time of the tics and clicks is far shorter than any of the musical information I am recording and at 16 bits and 44.1 kHz I can visually confirm them as being recorded rather faithfully since I have used an HP digital storage oscilloscope to do the same thing and I don't see any difference in the waveforms.

As far as USB not transmitting data perfectly, it has to or USB hard drives and the like would be impossible to use. Digital data is either correct or it is not, there is no middle ground at all.

I've been using an external USB drive case with a laptop hard drive for almost ten years now and I don't recall ever once having an error in reading a file I had written to that drive. I use the drive to lug around data from place to place on a regular basis.

I've run a webcam at 30 fps 640 x 480 on a twenty five foot USB extension cable with no amp and not had any problems at all with it. And this was about seven years ago.

With sufficient buffering on the DAC side, I see no reason why a USB DAC would not be fidelity limited by the precision of the DAC and amp and the accuracy and stability of the clock driving the whole thing. The buffering of the USB data may cause a latency of a millisecond or two but we aren't speaking of studio type software where latency is a concern.

As an example here is the spectral and normal view of a large click during music.

 

[tbonner1]

A friend of mine has a Visiondaw workstation that has incredibly clean sound, but they are expensive.

 

[TheVinylRipper]

Another example, this time during louder music with a smaller click..

Note how the click stands out in the spectral view.

 

[SysteX]

Quote:

Originally Posted by TheVinylRipper /img/forum/go_quote.gif As far as USB not transmitting data perfectly, it has to or USB hard drives and the like would be impossible to use. Digital data is either correct or it is not, there is no middle ground at all.

This is not the question. No one is claiming that the USB interface causes data corruption. If this were the case, the interface would have been dead long ago.

The issue is what the OS does to the data before sending it out through the USB port. Us bit-perfect zealots are not claiming that if the OS claims it is sending out data X, it's actually sending out data Y. What we are saying is that in the process from raw data file to USB transmission, the OS manipulates and changes the data.

I think that this subtle distinction is often misunderstood because we talk about "devices" being bit-perfect. This is a bit of a misnomer. By the time a device actually receives the data, it is either still intact and bit-perfect, or it has been manipulated. The "device" itself has little to do with this. It is simply a matter of what data the OS has been told to send and how it does so. What we should really say is whether or not a particular OS + software/driver chain is bit-perfect.

 

[vcoheda]

why do major amp manufacturers (RSA, HeadRoom, Single Power, HeadAmp) always demo their equipment at meets using CD players instead of computer based setups?

 

[audioengr]

Quote:

Originally Posted by vcoheda /img/forum/go_quote.gif why do major amp manufacturers (RSA, HeadRoom, Single Power, HeadAmp) always demo their equipment at meets using CD players instead of computer based setups?

They just have not discovered the advantage yet. Ray Samuels got a taste of computer audio at the last HeadFest. I think he will come around soon.

Steve N.
Empirical Audio

 

[SysteX]

Quote:

Originally Posted by audioengr /img/forum/go_quote.gif They just have not discovered the advantage yet. Ray Samuels got a taste of computer audio at the last HeadFest. I think he will come around soon. Steve N. Empirical Audio

Agreed. The way I see it, it's still a bit uncouth to use a computer as a true high-end audiophile source. Of course, this doesn't mean that it can't be such a source--just that it's not "PC".

(Sorry for the god-awful pun, but I had to put it in there...)

 

[bbrandt]

Great clarification on seperating out the software stack from USB, SysteX.

Bit errors *can* crop up in USB audio "over the wire".

USB is a robust data transfer bus. If a hard drive is sending a data packet across USB and a bit error occurs, the packet fails the check against the CRC embedded in the frame, and the host requests a re-send.

Audio is typically sent synchronously (isochronously) over the USB bus. If there is a bit error the host does not request a re-send, as that would break the audio stream.

It is completely possible to ensure a "bit accurate" transport over the USB link, but the audio has to be sent as asynchronous data, with adequate buffering on the other side.