[EliasGwinn]

Quote:

Originally Posted by Wavelength /img/forum/go_quote.gif This is why I think there are too many variables here to just state to a defacto standard that this or that is true. Thanks Gordon

Gordon,

I couldn't say it better myself. A systems result is only as strong as its weakest link. This is true with any multi-part system, and especially true with computer systems.

However, one can say what one's component is capable of. That is, we can say that the DAC1 USB, when used with a typical Intel/XP/2000/OSX system, is capable of bit-transparent playback.

We cannot, however, say that it will ALWAYS be bit-transparent no matter what other hardware/software/settings implemented upstream from it. Many third-party plug-ins you can download for your media player will put your audio through the washing machine and dryer before it gets to your audio device.

 

[FRANKe]

Hi Elias - let me just say thank you for your diligence in responding to the myriad of questions and concerns here.

And now, if you will, indulge me in another set of questions. You have been talking a lot about the goal of achieving "bit-transparent". And here is a little quote from your testing methods:

Quote:

Originally Posted by EliasGwinn /img/forum/go_quote.gif The testing consisted of the 'psuedo-random' bit-test that was mentioned in the press release. This is, quiet simply, testing "what-bits-go-in-and-what-bits-come-out". This is a standard test developed by Audio Precision, the leading audio electronics testing equipment manufacturer. When the Audio Precision (AP) sends a digital audio signal into a device, it checks to see if the exact same bits come out. So, for example, if the AP sends in 101100111000, a 'bit-transparent' data path will output the exact same bits: 101100111000. This was our testing proceedure.

So my question to you then, is it possible to pass this test (with the same bits coming out as went in), but have varying degrees of jitter? In other words, I'm not an (audio) engineer so I'm just trying to make sense of this as an audio enthusiast. Does this AP test take jitter into account? And can two output methods (one through kmixer and one through ASIO) both be "bit-transparent", but yet have different amounts of jitter (and hence sound different)? And if so, are you saying that the amount of jitter between these two methods doesn't matter because your DAC is immune?

Thanks.
-FRANKe

 

[Wavelength]

Quote:

Originally Posted by FRANKe /img/forum/go_quote.gif So my question to you then, is it possible to pass this test (with the same bits coming out as went in), but have varying degrees of jitter? In other words, I'm not an (audio) engineer so I'm just trying to make sense of this as an audio enthusiast. Does this AP test take jitter into account? And can two output methods (one through kmixer and one through ASIO) both be "bit-transparent", but yet have different amounts of jitter (and hence sound different)? And if so, are you saying that the amount of jitter between these two methods doesn't matter because your DAC is immune?

Elias, I think I can answer this.

Franke,

Fist off with USB you have no jitter on the interface itself because of the lack of clock. The only jitter you have in the system based on jitter is what we call intrinsic jitter. This is jitter that is a result of the recieving chips clocking maybe slow response on the pc and lack of acceptable buffer on the receiving side or whatever.

Therefore the AP test is as I described a MP3 and WAV file that can be played on any available software.

With most of these tests sets they do allow for the injection of jitter in the SPDIF realm and the rejection of said jitter can be tested in the analog or digital inputs of the test set.

Here in USB land jitter can be tested in the analog domain using what is called sidebands. These are usually shown as spikes in the output surrounding a test tone, like the JTEST (1/4 Fs at -6dB and 1 bit usually around 229Hz). Though the JTEST is not really relevant for USB only SPDIF. It is better to test with common frequency and look for side bands in the FFT plot.

The Miller Audio Suite is the most popular for this sort of test as it is very colorfull and used by Stereophile for testing dac's and jitter. Follow this link to see the Apple Airport Express on the Stereophile website:

http://www.stereophile.com/accessory...ple/index.html

Presently Ap tests iPod devices and any Windows based system using the files so does Miller. The Prism dScope is the only test set that can stream directly to a device.

But be forwarned on jitter testing and the numbers. The miller device with the 16 bit AD board Stereophile uses is only good to 130ps (I find this a little hard to believe for 16 bit board), the dScope at 24/192 is 100ps and the Ap standard ATS2 I think is 200ps and with the preformance option 150ps. I don't really think any of these test units can really test below 200ps. You really need a wavecrest and probe around internally to determine real jitter. One of these will set you back about the cost of BMW 7 series.

Thanks
Gordon

 

[EliasGwinn]

Quote:

Originally Posted by FRANKe /img/forum/go_quote.gif So my question to you then, is it possible to pass this test (with the same bits coming out as went in), but have varying degrees of jitter? In other words, I'm not an (audio) engineer so I'm just trying to make sense of this as an audio enthusiast. Does this AP test take jitter into account? And can two output methods (one through kmixer and one through ASIO) both be "bit-transparent", but yet have different amounts of jitter (and hence sound different)? And if so, are you saying that the amount of jitter between these two methods doesn't matter because your DAC is immune? Thanks. -FRANKe

Bit-transparency is independent of jitter. The AP can measure jitter, but the bit-test is not dependent of jitter. Comparing ASIO vs. kmixer with regards to jitter is not a valid comparison. Comparing PCI sound cards vs. USB would be more appropriate. Even then, there are different methods of operation which would need to be included in the comparison.

The Benchmark DAC1 and DAC1 USB are, in fact, immune to jitter. The DAC1 will perform identically regardless of how much jitter is present. I have posted an explanation of this earlier in the thread (maybe around page 3 or so...). You can also read about it on our website. Go to:

http://www.benchmarkmedia.com/dac1/

Then half-way down the overview section, there is a paragraph titled "Jitter-Immune UltraLock™".

Thanks for the questions...
Elias

 

[EliasGwinn]

USB interfaces will, in fact, have significant amounts of jitter if they are run in synchronous mode. Synchronous operation means that the host will dictate the sample-rate clock.

A lot of USB audio device are designed to run in asynchronous mode to eliminate the jitter, but the tradeoff is that, when in asynchronous mode, kmixer may have to sample-rate convert to conform to the clock of the device. This sample-rate conversion (as you all know) is extremely detrimental to the quality of the audio.

The Benchmark DAC1 USB runs in synchronous mode. The reason for this is that it lets the host (kmixer) operate at the original sample-rate of the audio being played at all times. If the kmixer is not forced to do any sample-rate conversion, it can maintain bit-transparent operation. The tradeoff, of course, is significant amounts of jitter arriving at the DAC1. This is not a problem for the DAC1 however, because Benchmark's UltraLock clocking system makes it immune to jitter (as I have explained in detail several times before in this thread).

Thanks for the questions...
Elias

 

[EliasGwinn]

The last post actually brings a very important point to mind...something that should have been said much earlier in this thread.

The behavior of Kmixer, etc is dependent on the device it is streaming to!!

In other words, kmixer may act differently for one USB audio device then it will act for another USB audio device. This may be the reason for a lot of misunderstanding about kmixer.

Most importantly, it should be said that all statements made by Benchmark (specifically me) concerning kmixer being bit-transparent is assuming the audio device being used will let kmixer operate bit-transparently.

 

[FRANKe]

Thank you Gordon and thank you Elias for the wealth of information.

I think I understand everything you guys said. And forgive me if I drag this out a little longer. But Elias, you are bursting a lot of people's bubbles defending kmixer the way you are, and so I'm just trying to wrap my head around something.

OK, the bottom line for me is that output from kmixer and ASIO "sound" different. I mean, heck, even different foobar ASIO plugins sound different. Elias, you are implying that kmixer is the one that is bit-transparent and, as you mused, some ASIO solutions are run through the washer and dryer. I thought ASIO "sounded" better and certain foobar ASIO plugins "sounded" even better because the audio stream and/or clock was more accurate and hence lower jitter. I mean even different computer configurations will sound different. Of course, this is all based on my personal comparisons, using a couple of different computers and laptops and with both a M-Audio USB Audiophile as well as a Wavelength Brick and Cosecant.

So if the differences in sound are not jitter related, are you implying that with each configuration change, the bits are changing? And/or are you implying that the Benchmark USB DAC1 is immune to different computer "tweaks"?

Thanks.
-FRANKe

Edit: sorry for the redundancy (I was typing the post at the same time as Elias' previous)

 

[EliasGwinn]

Franke,

In addition to my last few posts, I'll try to clarify a bit...

First of all, I want to address my stance on ASIO. I do not have enough experience with ASIO as a whole (API) to condemn or support the API. We have done some testing with devices which use ASIO, but I am not an expert on all the different facets of ASIO. (the washer and dryer comment was not directed at ASIO).

I believe that ASIO is probably a very good API, if used right. It has some limitations with regards to configuration, however, that make it less then appealing for an audio playback device. For example, only one audio app can access an ASIO driver at a time, unless the kmixer is placed in front of it. Also, my experiences with ASIO devices was that it did not follow the sample-rate dynamically. In other words, instead of simply streaming at the sample-rate of the audio app (synchronously), the sample-rate had to be specifically set within the ASIO driver (asynchronously).

With all that said, I will address your experiences with different audio configurations with your computer. The configurations within the computer will react dynamically to the audio device it is streaming to. In other words, it can not be universally stated that kmixer is better then ASIO, or vice versa. It depends on what device it is talking to.

A solid example of this: If device XX had the exact same USB interface as the DAC1 USB, asynchronous mode might sound significantly better then synchronous because, even though kmixer will convert sample-rates, it won't pass high jitter levels to the D-to-A. However, with the DAC1 USB, synchronous will sound much better because the jitter levels don't affect the D-to-A within the DAC1, and the kmixer won't convert sample-rates.

Different devices will react differently to different modes of operation within the computer.

Therefore, I cannot say that ASIO devices are inferior to native devices, or vice versa. All I can say with certainty is, the DAC1 USB will have identical D-to-A performance playing 96/24 audio through kmixer -> USB interface, as it will playing 96/24 audio straight from the digital signal generator of the AP -> SPDIF input of the DAC1. This is much I can confirm.

 

[jpelg]

Thanks for all the info, Elias.

I feel as if I've learned a lot from reading this thread, and do not have a headache as a result. Well done!

 

[EliasGwinn]

Thanks, jpelg!! That is what I strive for. You know, its not easy for us engineers to talk right. In fact, sometimes when people don't understand me, I instantly think its because they require different power supply voltages then what I'm supplying. Or we need a codec, one or the other.

 

[Wavelength]

Quote:

Originally Posted by EliasGwinn /img/forum/go_quote.gif USB interfaces will, in fact, have significant amounts of jitter if they are run in synchronous mode. Synchronous operation means that the host will dictate the sample-rate clock. A lot of USB audio device are designed to run in asynchronous mode to eliminate the jitter, but the tradeoff is that, when in asynchronous mode, kmixer may have to sample-rate convert to conform to the clock of the device. This sample-rate conversion (as you all know) is extremely detrimental to the quality of the audio. The Benchmark DAC1 USB runs in synchronous mode. The reason for this is that it lets the host (kmixer) operate at the original sample-rate of the audio being played at all times. If the kmixer is not forced to do any sample-rate conversion, it can maintain bit-transparent operation. The tradeoff, of course, is significant amounts of jitter arriving at the DAC1. This is not a problem for the DAC1 however, because Benchmark's UltraLock clocking system makes it immune to jitter (as I have explained in detail several times before in this thread). Thanks for the questions... Elias

Elias,

Actually USB does not have jitter in either mode. Jitter in SPDIF land basically is caused by the removing the clock from the data. In USB there is no clock.

Though all parts have intrinsic jitter that have clocked audio, USB experiences more of this than say a SPDIF receiver for many reason's but the primary ones are:

1) Lack of buffering
2) Lack of audio clock source
3) modulation from on board sources such as dac's and stuff

USB gather's it's clock from the timing of packets of data. The longer the buffer the more the in coming clock is averaged out and therefore the locked in the audio clock becomes. Parts like the PCM270x series have very little buffers. The TUSB3200 and TAS1020 have configurable buffers and work much better. You can use USBVIEW.exe on the PC to look at the enumeration tables to see how large the incoming buffers are.

USB runs at 12MHZ, wereas most audio does not run any were close to this frequency. Therefore the audio clock is being derived from a source that is not the best reference for audio. This is true in ISOSYNC mode only, in ASYNC mode we do have to give the clock to the controller and it paces the computer to that clock.

Some of the combo chips like the PCM270x series have onboard class D headphone amplifiers and stuff that really stink up their preformance. Also their SpAct controller goes bizurt every 80-90 seconds.

Anyway... Elias with XP ASYNC mode is not supported. You would have to have drivers for that.

But in the TAS1020 (and TUSB3200) you can tune the intrinsic jitter very low. First the part is capable of Input and Output. If you are just using it as a dac then you can consume the resources for the ADC and make longer buffers. You can also tune the ACG (Adaptive Clock Generator) over the longer buffers and get the jitter down really low.

To answer Franke question I think I would have to setup some tests. One that would be interesting would be to set the USB controller to ISO mode 16 bit and 44.1K only. Then send the test tone down via the KMIXER from a standard red book track. Then ASIO and KERNEL streaming.

So far in the past 4 years of designing USB DACs this is what I can tell you. Not all ASIO's work the same way and the results vary from PC to DAC. Kernel streaming can result in some systems locking up. I have seen the same setup on one machine via the KMIXER go to 48K and another with the same track stay at 44.1.

In all the MAC is more consistent than the PC in it's output.

Well going to shut down and play some guitar.

Later,
Gordon

 

[thomaspf]

Very accurate with one minor variation. XP does actually support async audio in USBaudio.sys, however, the Vista implementation is more faithful to the standard.

Cheers

Thomas

 

[Wavelength]

Quote:

Originally Posted by thomaspf /img/forum/go_quote.gif Very accurate with one minor variation. XP does actually support async audio in USBaudio.sys, however, the Vista implementation is more faithful to the standard. Cheers Thomas

Thomas,

Sorry if this is the case but on the two PC's I use for testing they immediately reboot when I plug in the USB DAC with it set to ASYNC in the Enumeration. I recompile with ISO setting and it works fine.

I talked to the company who supports the TI USB Audio solutions and they say the same thing. They say it requires a driver before it will work that way.

If there is a way, please tell me who too talk to.

Thanks
Gordon

 

[thomaspf]

I have tried this with the Audigy 2NX. The Audigy works in async mode and if you do noy install their custom driver the system driver works just fine in stereo mode. The Audigy however does use a more general USB controller. There is also an older Emagic EMI 2|6 that works just fine in async mode.

As I mentioned above the Vista implementation is more faithful to the standard.

I would just report this as a bug and see whether it makes the bar. This is the first time I hear about an instant reboot when try to negotiate async. I am glad to hear you are working on this.

Cheers

Thomas

 

[lowmagnet]

My DAC1 arrived, and it's working great. Thanks Benchmark!

Added: After 3-4 hours listening to this, it's really just perfect. I'm not used to spending this much on sound hardware, but it's obviously money well-spent. It also matches my G5 and monitor in finish