Benchmark DAC1 now available with USB - Page 93

Well, here we go again. So, you are claiming now that your adapter does not undergo the standard volume processing in kmixer?

Last time I looked at the DAC1 it still used the standard USBaudio driver in Windows and that always applies volume processing on 16/44.1 streams no matter which firmware is connected. Have you now concluded otherwise?

Cheers

Thomas

No, the DAC1 does, in fact, use kmixer (unless specifically bypassed). However, the DAC1 USB may interact with kmixer differently then other USB interfaces (with regard to clock control and sample rate conversion).

The debate over whether kmixer is bit-transparent is something entirely different.

Thanks,
Elias

Well to start with the DAC1 does not interact with kmixer at all. The DAC interacts with USBaudio.sys and that driver interacts with kmixer. In fact is does that the same way it interacts for any other device that uses the standard Windows driver.

The only difference I have found looking at the way the firmware behaves is that it registers itself as a device that only supports 24 bit data and if my memory serves me correctly all the relevant bit rates 44.1, 48, and 96Khz. So the main difference is that firmware does not support 16bit mode which is natively supported by the USB chipset. I also understand that Centrance has implemented improved buffering which will reduce drop outs which is a great thing but orthogonal to the kmixer issue.


If I interpret what you are saying correctly then you only clarify how kmixer works. No sample rate conversion if the sound card supports the bit rate that is requested by the app. No mixing or resampling if there is only a single app.

That is indeed correct and of course applies not only to the DAC1 but to any sound card or USB adapter that supports the standard sample rates. The DAC1 works well in that regard and so do many other USB adapters using the TAS1020 chip.

While we are talking about this. Have you now concluded that kmixer is not bit transparent unless explicitely bypassed?

Cheers

Thomas

I think Thomas replied to this, but really common the USB driver cannot mystically control the upper layers of the audio stack.

Elias,

Actually I understand this very well. I bought your unit because of the claims you made. I put it under some pretty heavy testing. Since I wrote my code for Wavelength and code for other companies and have the emulator here and a USB analyzer, I can tell you a few things.

First the Centrance code is based on the TI sample code called "REFERNCE". Basically what they did was add support for 48. 88.2 and 96 which is pretty easy to do. They actually could have changed the SoftPLL code a little more to add longer delays and less of an incident to the clock changes of the host.

But ok... here is what you need to know about the TAS1020 that really has nothing to do with coding at all.

The TAS1020 has firmware and software (Centrance in your case). The firmware is solid in ROM code and cannot be altered. The firmware handles what is called the Serial Interface Engine (SIE). The SIE works with the firmware to gather and send USB packets to the HOST. The SIE will compare the CRC of a packet and strip the header info and present only audio data to the circular buffer used to fuel the DAC or ADC. If the CRC is incorrect an error is indicated and the error count is incremented. The packet is still applied to the circular buffer. The source code for the firmware ROM is included in the REFERNCE code because the firmware and software are linked together.

Actually the software really has no interaction in receiving a packet of ISO DATA. Sure it sets up the DMA pointers lengths and such but other than that it has nothing to do with it.

Therefore when a CRC error happens the Application would not even know that is happening. Just like if the transport feeding the SPDIF too your dac get's an error your dac has no idea. As well as if the SPDIF receiver in your DAC get's and error it doesn't really do anything as it can't. What's it going to do FIX it.

Allot of these USB repeaters cause CRC errors because they cannot retain what is called the Differential EYE that is required for good USB communications. This especially true when you are talking larger packets of data like 576 bytes per 1ms that you would need for 24/96.

I would suggest you get a USB Analyzer and see for yourself. Though that won't tell you if the TAS1020 got and error but if the Analyzer does then you know for sure the TAS1020 would.

Elias, the idea of a forum like this is to exchange information. One of the biggest problems with Computer Audio is that there is so much misinformation out there that people have been lead down a path of poor sound and feel the technology is not there yet.

Let's not add to that problem.

Thanks
Gordon

I have a question regarding the output of a -1db 1khz sine wave measured on the XLR outputs of the DAC1.

I set the Calibrate output to 4v and then applied the Replay Gain in J. River which, after analysing the file, used a -19db reduction to achieve the target -89db. Accordingly, the voltage dropped significantyly on the DAC1. IIRC, it was .5mv.

I figured I could simply crank up the pots to 4v, with the volume reduction applied, and achieve a new reference level that incorporated the volume leveling that is applied by J. River.

But I can't seem get the output up over 1.2v with the -19db (as shown in J. River) reduction.

I ended up setting the DAC1 with the unadultered -1db 1khz sine wave to 7.7v and then used the volume leveling. I see peaks of 4v now while playing music out of the DAC1 while volume leveling is active.

I'm obvously confused as to why the signal was unable to be increased to a 4v; was the -19db reduction crushing the signal? I'm a bit confused on how to find a "correct" calibrated output while using such volume leveling.

DC

Gordon, Thomas, Elias,

The crux of this perennial kmixer/transparency/firmware/yada-yada-yada debate is whether the bits make it from the app to the USB port without being changed. It seems that Gordon's USB analyzer can detect errors but cannot compare the data received to the data that was sent. Plus it's probably not something your average computer user would have sitting in a box somewhere.

I'm no driver/firmware developer, but looking at some of the architecture diagrams for the windows sound system (on XP), I see that filters can be inserted between kmixer and the driver. I've pondered looking into writing a filter that would grab the stream, dump it into a file, then allow post-playback comparison with the source. This seems like an obvious way to figure out what's going on, so there must be difficulties with this approach that I'm not aware of that have prevented others from doing it. Things like timing and/or latency.

Do any of you have experience with this and can maybe advise me about what the pitfalls would be?

Thanks,
- Eric

I have done simple straight forward recordings of the stream from a digital output.

Steve is now shipping the Centrance or I should probably say a variant of the Centrance USB firmware on his adapters and they register the same way the DAC1 does.

The result just confirmed what you do expect from kmixer in the middle. It does ever so slightly change the bits.

It is also straight forward to get around this. Just use direct kernel streaming and you are bit transparent. I believe I suggested this some time back very early on this thread.

The DAC1 is a great product and it is a good choice that it uses the stable standard driver. However, in order to get bit transparent playback you need to bypass kmixer like you have to do with any other USB adapter using that driver.

Cheers

Thomas

I hope you don't think that I have intentions to mis-inform. We may have different ideas, but I try to speak for myself and my own knowledge. I don't claim them to be absolutes.

We appreciate your contribution to this thread, but please don't instigate accusations and finger pointing. We all have the same objectives...to understand all things audio as much as possible.

Thanks,
Elias

I will not be active on this forum until next week. Have a great holiday!

Thanks,
Elias

Eric,

I have many testing devices including the Prism dScope III which is the only audio test gear that can stream out USB natively with test data and compare the analog signal.

I use the USB Analyzer to test the USB line itself. That being errors and data and yes I can capture data with it and compare it too the source.

But your method maybe better or an even better method would be too write a fake audio output device driver which would you could store the streamed data.

All of these would be helpful in determining what is going on in the audio stack.

Thanks
Gordon

I'm more than a bit confused by this post........

If a 0 dBFS digital signal should produce a 4 Vrms analog signal at the XLR's on the DAC1, a -20 dBFS signal should only produce 0.4 Vrms (20 dB reduction is equal to a 10x reduction in voltage.)

If you adjusted a -20 dBFS signal to 4 Vrms at the outputs of the DAC1, a 0 dBFS digital signal would drive the output way beyond clipping. Seems to me that any output stage wouldn't be designed with such massive gain, anyway.

Why would you be need such a high reduction in level in JRiver?

EDIT: After looking at the specs on the Benchmark site, I remain confused.....

According to Benchmark, with the attenutation jumpers set for no attenuation, the output range on the XLR's for a 0 dBFS digital input is +9 to +29 dBu, which I calculate to be 2.18 Vrms to 21.8 Vrms (0 dBu = 0.775 Vrms.)

If the maximum digital signal that you will send to the Benchmark after replay gain adjustment is roughly -19 dBFS, the max output from the balanced connections with the adjustment pots cranked to the max should be +10 dBU (the stated max output level of +29 dBu, less 19 dB.) +10 dBu is equivalent to 2.45 Vrms....or about double what you measured based on this:

Are you consistently measuring the output level between pins 2 and 3 of the XLR's (between the "hot" and "cold" signals) or did you possibly measure between pin 2 and pin 1 (hot to ground) or pin 3 and pin 1 (cold to ground)? If you measured from either signal pin to ground, you should get 1/2 the voltage measured between the signal pins.

What are you striving for when you refer to a " 'correct' calibrated output"?

I've had a long day , and plan to post more details tomorrow but here goes. Thanks for you interest.

Only the -1db 1khz sine wave results in -19db in J. River with Replay Gain enabled; I rarely see reductions this extreme. Usually the average is -8db to -12db. Since the sine wave is close to clipping, it accordingly needs a great amount of reduction to hit the target -89db that RG uses as the standard.

I have the 3rd pin floated on the XLR output cables. I was measuring the RCA hot pin and the RCA body.

DC

elias:

could you please comment on the difference in application between the coaxial digital input and the XLR balanced digital input on the DAC1. for example, if i intend to use the DAC1 with a balanced setup (amp and headphones), and use the coaxial instead of the XLR digital input from my music server to the DAC1, does this mean the setup is NOT balanced?

basically, is there a difference between these two setups.

1. MusicServer (digital coaxial cable) > DAC1 (XLR analog cable) > Bal Amp > Bal HP

2. MusicServer (digital XLR cable) > DAC1 (XLR analog cable) > Bal Amp > Bal HP

thanks

That explains it...you 1.2 Vrms measurement was what you should have seen for a -20 dBFS digital input. What I don't get is why you want 4 Vrms peaks, because that's way beyond the level that clips your monoblocks (which are spec'ed for an input sensitivity of only 1 volt!)

Why do you bother with XLR-to-RCA cables when the DAC1 has RCA outputs?

resolving somewhat mixed metaphors, analog and digital "Balanced"

(In that which follows, Wikipedia is actually helpful in riding to the rescue... take a look at AES/EBU - Wikipedia, the free encyclopedia , as well as the "Hardware Specifications" section of S/PDIF - Wikipedia, the free encyclopedia )



As Elias recently posted innocuously that he'd be away for a few days (which may mean he's off to some recording / partying bacchanal or somesuch )... and as I'm terribly awake....to hopefully help to clarify for you, let's address the two "Balanced" signal paths in your system... a priori, I have no association with Benchmark except owning a DAC1, among several DACs.



Short version:

In simplest terms, no, there is no significant difference (caveats not to be beaten to death here: cable quality, environmental noise, standard topics of debate wrt cable design, digital data transmission, noise isolation, yadayada).

Digital audio data is transferred to a DAC on optical fibre, balanced cable or unbalanced cable. In a well-designed system, the bits of digital audio data "arriving and greeted by the DAC" will be identical no matter which of those "digital cables" is used.

Without getting into arcane stuff about digital data transmission: it shouldn't matter if you connect to the DAC1 from a S/PDIF source using S/PDIF coax cable (RCA connector) or from an AES3 aka AES/EBU source using AES/EBU balanced cable (XLR connector); although between these two there may be a preference for AES/EBU connection (ie in an electrically-noisy environment). And as the marketing makes clear, Benchmark are particularly proud of their digital receiver designs and jitter tolerance...

The DAC receives, understands, decodes and unpacks the bits of digital audio data which arrived from the digital source (ie your MusicServer).

The DAC then performs Digital-to-Analog conversion of the audio samples, creating an analog output signal. This analog output signal is buffered into a robust form which can drive cables and attached equipment (and, with some DACs, apparently also some peoples' balanced heaphones ), and is provided in balanced and unbalanced analog output signal versions on respective XLR and RCA output jacks.

Hence, balanced electrical transmission of digital audio data into the DAC1 is a function which is separated (thru the process of Digital-to-Analog conversion) (and a bunch o' electrical isolation stuff) from balanced electrical transmission of analog audio signals out of the DAC1 to your amp...

Your two "balanced" electrical transmission functions are separate; for your concern, which is the analog side o' things, you are "balanced"* no matter which flavor of digital input you choose to utilize. [* comment here is wrt analog output signal connection, not your frame of mind, disposition, Head-Fi wallet utilization profile, etc. ]



Less-short version:

You are looking at two instances of signal transmission:

1/ (Digital source = MusicServer) > (balanced or unbalanced

digital audio signal) > DAC1and then

2/ DAC1 > (balanced or unbalanced

analog audio signal) > (analog playback = amp & HP)in your particular case, 2/ defaults to

DAC1 > (balanced

analog audio signal) > balanced (amp & HP)

Digital Audio path into DAC

The digital audio information which is output from your MusicServer can (assuming availability of appropriate hardware output connections) be transmitted onward in one of several data formats, over different possible physical transport links:

data format: either professional (AES/EBU) or consumer (S/PDIF); "S/PDIF is essentially a minor modification of the original AES/EBU standard for consumer use, providing small differences in the protocol and requiring less expensive hardware" (credit Wikipedia)

physical transport (ie the "digital cable"): consumer S/PDIF format data is generally carried on either TOSlink optical or RCA-terminated 75-ohm unbalanced coax cable; professional AES/EBU format data is generally carried on either XLR-terminated 110-ohm balanced coax cable or BNC-terminated 75-ohm unbalanced coax cable. You will often see a small RCA-to-BNC connecter/adapter widget allowing you to use a "typically-available" RCA-RCA 75-ohm coax cable with a BNC input connector. Less commonly, you may also see ST (aka "glass" or "glass fibre") as another type of high-end optical connector. (IIRC, Benchmark's DAC1 manuals have a useful section addressing the different connectors.)

There are many posts in many fora about the merits of coax vs TOS, or TOS vs coax; jitter tradeoffs; possible implementation-dependent TOS performance limitations for 192 Khz; etc, etc...you can decide for yourself..... also some interesting observations and opinions about cable length considerations on SPDIF coax given quality of the particular receiver circuitry used. Will leave it to Benchmark to express their own opinion wrt any of those.

(Cable cognesenti and high-speed data transmission folk, please don't bash the oversimplified following): without getting into big cable shootout stuff, simply recall that even though the signal from your MusicServer is digital audio, it is still a transmission of several channels of audio data, along with associated subcode, headers, etc., as a stream of packaged packets of "bits," via electrical signals (which optimally represent those bits by looking something like "square wave signals" with high-speed transitions between two different voltage levels), traveling in analog electrical fashion over good ol' wires..... so there can be benefits in "balanced" electrical connection, similar to the case with what you would consider a more-traditional audio-frequency analog signal.

There are those (myself included) who opine that, if you have the appropriate AES/EBU gozouttas and gozintas (or, for the non-EE folk, that translates to output connectors and input connectors), with bang-for-the-buck consideration AES/EBU can be a preferable hardware interconnect for digital signals. However, S/PDIF coax can certainly be just fine. Both are generally considered preferable to TOS optical.

Input receive, decode, unpack; and data conversion processes follow as noted previously.



Analog Audio path out of DAC

You've obviously studied, understood and come to your conclusions, and are using balanced connections in the analog audio side of the system. So, no explanation necessary.



So: your MusicServer's digital audio data can be transmitted on balanced or unbalanced cables to the DAC1; whichever is used, the digital audio signal data which is received, decoded, and disassembled-into-two-channels-of-audio-samples by the DAC1 will* be the same. (* this is where the high-speed data transmission geeks, experts, and opinionators will have itchy keyboard fingers, but for sake of Head-Fi, if the equipment manufacturers have done an expected good job, the correct bits will arrive at the DAC1, and will be correctly received, understood and decoded for the next step: conversion to analog).

The DAC1 will then perform Digital to Analog conversion on those two channels, and the D/A chip output will be provided at the DAC1 output in both balanced and unbalanced voltage-drive versions. You are using the balanced analog outputs on XLR connectors.

So as noted earlier in the non-War-and-Peace Short Version, balanced electrical transmission of digital audio data into the DAC1 is a function which is separated (thru the process of Digital-to-Analog conversion) (and a bunch o' electrical isolation stuff) from balanced electrical transmission of analog audio signals out of the DAC1 to your amp...

Your concern is the analog part of the equation following the DAC, and is "balanced" no matter which flavor of digital input you choose to utilize.



HTH, we aim to entertain

emmo = asleep
dad = still awake