[Lil' Knight]

Yup, I'm also using it with Vista 64bit and have zero problem. It's such an awesome equipment. I almost load it at 100%

XLR and RCA outputs to my amps and headphones jack for my portable phones.

 

[Scrith]

I'm using Vista64 Ultimate and the DAC1 is working great for me (whether I use DirectSound, KernalStreaming, or WASAPI output from Foobar2000).

All my DAC1s run a bit warm, but not certainly not hot to the touch.

 

[Mazz]

Quote:

Originally Posted by EliasGwinn /img/forum/go_quote.gif You might say, "You could eliminate the ASRC if there was no jitter!" Sure, but then the digital filters wouldn't perform as well. There are major sonic benefits to converting the sample-rate to 110 kHz, and Mr. Hansen isn't considering this at all.

Well, to be precise (as in the joke about the statistician, applied mathematician and pure mathematician) ... you COULD eliminate the ASRC if there was no jitter AND STILL convert the sample-rate to 110kHz - using an SRC.

As I pointed out earlier in the thread, SRC has major benefits. The correct solution is a deterministic algorithm - there's no guesswork or implementation variations involved - and thus any competent programmer should be able to write a perfect implementation. (The fact that many implementations are broken doesn't mean a correct implementation is impossible.) It's also immune to jitter and it doesn't add any jitter. This is because inputs to the algorithm are not clocked - they are merely sequences of samples taken (implicitly) at a fixed known clock rate - as are the outputs.

Quote:

Originally Posted by EliasGwinn /img/forum/go_quote.gif Isochronous means that the data transfer is happening at a regular (periodic) rate.

Well, to be precise...isochronous means that the bandwidth is reserved on the USB bus for the particular USB endpoint. Whilst it's true that the USB bus operates at a fixed data rate, there may or may not be any data sent during any particular timeslot reserved for that device. (I haven't looked at the specs to see what the bandwidth allocation granularity is, but I'd bet good money it isn't fine enough to distinguish between some of your example rates such as 44.1001kHz and 44.1002kHz.) If data is sent during some timeslots and not during others, most people wouldn't consider this to be "data transfer happening at a regular (periodic) rate".

Furthermore, some readers might be lead to believe by this that audio travels over the USB bus at (say) 44.1 kHz (within error bounds), which I'm pretty sure isn't true. The audio bits travel in packets at the USB bus data rate which IIRC is measured in megabits/second...and then the DAC has to infer what the computer's playback frequency really is somehow.

Quote:

Originally Posted by EliasGwinn /img/forum/go_quote.gif It's not that YOU need to use SRC on your computer... Its that the computer will have to re-sample the data to correspond to the new clock...the master clock....the clock from the USB audio device. I posted about this previously (somewhere around +/- post# 2100).

That is one way to deal with the problem, but as we have discussed earlier you can deal with it in other ways. For example, much like Scrith was saying, you can have the computer speed up/slow down its average transfer rate in response to the DAC. But as you pointed out in response, we (probably) don't have audio drivers built into OSes and media players that can handle these types of control requests (yet). It's not hard to see how to modify existing media players & drivers to do so, but I don't yet see the market demand that will drive such changes. If I had to guess, I'd say an Open Source media player/driver combination might be the first to do it. I suspect this is the biggest issue with asynchronous mode today. It would be interesting to obtain an async mode DAC and see if one can observe these types of issues in practice with today's software stacks.

Quote:

Originally Posted by EliasGwinn /img/forum/go_quote.gif When we designed the Benchmark/Centrance solution, we said, "Why don't we allow the computer to be master so the sample-rate can stay consistent until it enters the DAC1? Jitter isn't an issue...only bit-transparency. Just send us the proper data, and we'll take care of the rest!!"

The only problem is that IIRC the sample rate doesn't stay that consistent in a computer - the clocks tend to be a bit loose. And you have the media player's playback sample rate, embedded in the USB bus data transfer rate, so it's not quite as simple as you made it seem.

In fact "Just send us the proper data [and desired sample rate], and we'll take care of the rest!!" seems to be a great description of the guiding philosophy for asynchronous mode USB. If the software stacks ever support it properly, it seems clear that it would be a technically superior solution. Whether you can hear the difference in practice or not is another question...

 

[EliasGwinn]

Quote:

Originally Posted by tubaman /img/forum/go_quote.gif From my prior experience with the DAC1 USB I know the unit can run pretty hot, but how hot is too hot? Is overheating ever a concern? I put a HRS Damping Plate, which is 5.5 x 4.5 x 0.7 (inch) and basically made of plastic, on top of my DAC1 PRE. Plastic surface supposedly traps heat, should I be concerned about this? HRS Damping Plate: Damping Plate reduces vibrations on audio or video performance

Tubaman,

I would recommend not using this damping plate. It will not affect the performance of the DAC1 USB, and it may cause the components to have a shorter life-span because of the increased heat.

Thanks,
Elias

 

[dvse]

Quote:

Originally Posted by EliasGwinn /img/forum/go_quote.gif Example: What if Mr. Hansen's USB audio device says, "Send me all audio data at my sample-rate: 44.1001 kHz (or 48k, or 96k)." USBaudio.sys looks at the audio stack, which is sending audio at 44.1002 from iTunes. How does it reconcile that difference? It must re-sample.

Elias,

Surely this is some misunderstanding? The standard way audio playback is implemented from the application side is that the application writes PCM to a buffer and either polls in a loop or gets an event when the buffer needs to be refilled. Actual sampling rate doesn't come into this at all, it's just a setting on the playback device, transparent to the application. There is no need to resample anything. This is the same flow control idea as implemented by asynchronous USB receivers (and just about everywhere else except digital audio, it seems).

 

[lyricalmoments]

I recently purchased the DAC USB, tested it at the shop running windows media player and it was fine...

Brought the unit back home and hooked it up to my mac pro and realised that the bass and mids were very unbalanced, culprit happened to be Itune's DSP features (the Sound Enhancer was ON, dur).

I'm just wondering if there are any recommended software player for Mac OS 10.5.6 that's better than Itunes?

Thanks!

 

[lyricalmoments]

Nonetheless, I've got the Benchmark DAC USB hooked up to my Yamamoto HA-02 headphone amp and AKG 701 and I'm loving it!

 

[EliasGwinn]

Quote:

Originally Posted by dvse /img/forum/go_quote.gif Elias, Surely this is some misunderstanding? The standard way audio playback is implemented from the application side is that the application writes PCM to a buffer and either polls in a loop or gets an event when the buffer needs to be refilled. Actual sampling rate doesn't come into this at all, it's just a setting on the playback device, transparent to the application. There is no need to resample anything. This is the same flow control idea as implemented by asynchronous USB receivers (and just about everywhere else except digital audio, it seems).

Sample rate is not just a setting. Even if the data is not being transferred at the specified period, the sample rate of the audio is a very important, very specific quantity.

The question is, what happens when the sample-rate of this audio is different from the sample-rate of the USB device? If the playback sample-rate is based on the USB device instead of the audio data, any discrepencies in sample-rate will result in a combination of three possible outcomes: 1. sample-rate conversion; 2. pitch shifting; 3. phase shifting because of repeated or skipped samples.

The way to avoide this is by allowing the comptuter to keep its clocking system in sync, so that the data arrives at the DAC just like with any other digital source. Yes, there will be jitter, but there is jitter from every digital audio source, through every digital interconnect, and at every digital audio receiver. Dealing with jitter is, and always will be, essential. Re-inventing the wheel to shed a little bit of jitter at the risk of other sonic pit-falls is not an approach that we are interested in.

Thanks,
Elias

 

[EliasGwinn]

Quote:

Originally Posted by lyricalmoments /img/forum/go_quote.gif I recently purchased the DAC USB, tested it at the shop running windows media player and it was fine... Brought the unit back home and hooked it up to my mac pro and realised that the bass and mids were very unbalanced, culprit happened to be Itune's DSP features (the Sound Enhancer was ON, dur). I'm just wondering if there are any recommended software player for Mac OS 10.5.6 that's better than Itunes? Thanks!

Try this:

ITunes-QuickTime for Mac - Setup Guide - Benchmark

Let me know if you have any other questions.

Thanks,
Elias

 

[Mazz]

Quote:

Originally Posted by EliasGwinn /img/forum/go_quote.gif The question is, what happens when the sample-rate of this audio is different from the sample-rate of the USB device? If the playback sample-rate is based on the USB device instead of the audio data, any discrepencies in sample-rate will result in a combination of three possible outcomes: 1. sample-rate conversion; 2. pitch shifting; 3. phase shifting because of repeated or skipped samples. The way to avoide this is by allowing the comptuter to keep its clocking system in sync, so that the data arrives at the DAC just like with any other digital source.

More precisely, that should read "One way to avoid this is..." rather than "The way...". A different way is by having the USB device CHANGE its playback sample rate to conform to the sample rate setting of the audio stream.

Quote:

Originally Posted by EliasGwinn /img/forum/go_quote.gif Yes, there will be jitter, but there is jitter from every digital audio source, through every digital interconnect, and at every digital audio receiver.

More precisely, there is jitter at every digital audio receiver ONLY where the data clock is implied or transmitted with the audio sample data. If you can provide an interconnect that sends the data without transmitting data clock signals (actual or implied), you eliminate one entire source of jitter.

Quote:

Originally Posted by EliasGwinn /img/forum/go_quote.gif Re-inventing the wheel to shed a little bit of jitter at the risk of other sonic pit-falls is not an approach that we are interested in.

Firstly there's no re-invention here. My several-year-old Rotel AV receiver already changes its playback sample rate for SPDIF inputs (and I bet it was far from the first to do this). When I view digital TV the receiver runs at 48kHz; when I play ripped CD audio it runs at 44.1kHz. There are even protocol bits in the SPDIF headers to specify the desired playback sample rate - and that protocol has been around for many years. If Rotel were to add a USB interface then playback rate switching could also be done very easily for USB.

And secondly, as an engineering tradeoff, I will always take "eliminate the problem with no downside" solution over other alternatives. I'd lay good money that practically EVERY asynchronous USB DAC will switch sample playback rates to match the audio stream settings - because it's an old well-known mechanism, it is very easy to do, and (if the software stack works the way dvse says it does) then there is no risk of "sonic pit-falls" in comparison to clocking data on the computer.

 

[dvse]

Quote:

Originally Posted by EliasGwinn /img/forum/go_quote.gif Sample rate is not just a setting. Even if the data is not being transferred at the specified period, the sample rate of the audio is a very important, very specific quantity. The question is, what happens when the sample-rate of this audio is different from the sample-rate of the USB device? If the playback sample-rate is based on the USB device instead of the audio data, any discrepencies in sample-rate will result in a combination of three possible outcomes: 1. sample-rate conversion; 2. pitch shifting; 3. phase shifting because of repeated or skipped samples. Thanks, Elias

Elias,

The way asynchronous USB works is as follows:

1.) Application fills a memory buffer with PCM and sets the sample rate on the playback device (assuming that it is supported)
2.) USB driver sends packets to the device which are stored in the local buffer; playback starts, going by the local clock
3.) Once a certain part of the local buffer is consumed, a control message is sent to the driver, which sends more packets from its buffer or if it's running low, notifies the application to refill.

The entire chain works by the clock local to the DAC and any synchronisation issues are avoided. This works because the channel bandwidth is much greater than what is actually needed to feed the DAC.

No resampling occurs anywhere in the chain unless the original PCM uses some sampling rate not supported by the device (and it's easy to support all the standard ones).

This requires different behaviour from the driver, but is completely transparent to the application.

 

[EliasGwinn]

Quote:

Originally Posted by Mazz /img/forum/go_quote.gif More precisely, that should read "One way to avoid this is..." rather than "The way...".

I'll give you this. I try to avoide speaking in 'absolutes'...I let this one slip. Good call...

Quote:

Originally Posted by Mazz /img/forum/go_quote.gif A different way is by having the USB device CHANGE its playback sample rate to conform to the sample rate setting of the audio stream.

This is how synchronous USB works. The TAS1020B takes its cue from the incoming sample rate, adjusts its clock accordingly, and sends the data out at the native sample rate of the audio data.

Quote:

Originally Posted by Mazz /img/forum/go_quote.gif More precisely, there is jitter at every digital audio receiver ONLY where the data clock is implied or transmitted with the audio sample data. If you can provide an interconnect that sends the data without transmitting data clock signals (actual or implied), you eliminate one entire source of jitter.

You're talking about using I2S-type transmission...data with no clock. This involves using large buffers, buffer management, and some sort of sample-rate information that could be usually obtained by reading SOF.

This isn't far from the way UltraLock works. The clock-portion of the incoming data is completely thrown out. The data is buffered, the ASRC determines the sample by averaging the incoming rate over a long period of time (64 samples), affectively eliminating any affect of jitter at or above 1 Hz.

The sample-rate conversion (to 110kHz) is there to optimize the filters in the DAC chip.

Quote:

Originally Posted by Mazz /img/forum/go_quote.gif Firstly there's no re-invention here. My several-year-old Rotel AV receiver already changes its playback sample rate for SPDIF inputs (and I bet it was far from the first to do this). When I view digital TV the receiver runs at 48kHz; when I play ripped CD audio it runs at 44.1kHz. There are even protocol bits in the SPDIF headers to specify the desired playback sample rate - and that protocol has been around for many years. If Rotel were to add a USB interface then playback rate switching could also be done very easily for USB.

I'm not familiar with your receiver, but it is probably just sensing the sample rate and displaying the result. It probably uses the clock on the SPDIF line for the conversion with a PLL for jitter attenuation, as most DAC's do.

Quote:

Originally Posted by Mazz /img/forum/go_quote.gif And secondly, as an engineering tradeoff, I will always take "eliminate the problem with no downside" solution over other alternatives. I'd lay good money that practically EVERY asynchronous USB DAC will switch sample playback rates to match the audio stream settings - because it's an old well-known mechanism, it is very easy to do, and (if the software stack works the way dvse says it does) then there is no risk of "sonic pit-falls" in comparison to clocking data on the computer.

Ideally, every engineer would love to eliminate a problem without a downside. However, that scenario isn't really a 'tradeoff'. When a real tradeoff situation comes about, you must determine the best solution that acheives the most important objectives.

I will admit, I haven't seen or heard everybody'sasynchronous solutions. I'm speaking from what we had learned when we developed our USB solution 2 years ago, and what I've learned since from reading and talking with other engineers. So, it is possible that there is an asynchronous solution out there that has no sonic pit-falls. But I'll have to see it to believe it.

Thanks,
Elias

 

[EliasGwinn]

Quote:

Originally Posted by dvse /img/forum/go_quote.gif Elias, The way asynchronous USB works is as follows: 1.) Application fills a memory buffer with PCM and sets the sample rate on the playback device (assuming that it is supported) 2.) USB driver sends packets to the device which are stored in the local buffer; playback starts, going by the local clock 3.) Once a certain part of the local buffer is consumed, a control message is sent to the driver, which sends more packets from its buffer or if it's running low, notifies the application to refill. The entire chain works by the clock local to the DAC and any synchronisation issues are avoided. This works because the channel bandwidth is much greater than what is actually needed to feed the DAC. No resampling occurs anywhere in the chain unless the original PCM uses some sampling rate not supported by the device (and it's easy to support all the standard ones). This requires different behaviour from the driver, but is completely transparent to the application.

When you say "local buffer", do you mean the buffer in the USB receiver chip in the USB device?

 

[Quaddy]

Quote:

Originally Posted by Mazz /img/forum/go_quote.gif More precisely, there is jitter at every digital audio receiver ONLY where the data clock is implied or transmitted with the audio sample data. If you can provide an interconnect that sends the data without transmitting data clock signals (actual or implied), you eliminate one entire source of jitter.

as far as i know, a USB interface/interconnect does just this, it doesnt send down the interleaved data along with the signal, but am not so sure its as clear cut as to completely eliminate jitter because of the lack of data in the equation, this must reduce jitter substantially though, besides AFAIK a realtime stream with interleaving(eg. toslink and SPDIF) can increase the likelyhood of transmission errors resulting in harmonic distortion, SNR and gain discrepancies/anomalies compared with non-interleaved carrier...

or does the USB interface & interconnect still send down data clock signals even when it omits to send down sample rate data?

bring back the manchester code

j/k

 

[Mazz]

Quote:

Originally Posted by EliasGwinn /img/forum/go_quote.gif This isn't far from the way UltraLock works. The clock-portion of the incoming data is completely thrown out. The data is buffered, the ASRC determines the sample by averaging the incoming rate over a long period of time (64 samples), affectively eliminating any affect of jitter at or above 1 Hz.

Right, and that's really great for a whole lot of use cases - especially for any source/input connection that has incoming jitter, which is most of them. (However it's not true that the "clock-portion of the incoming data is completely thrown out" because you MUST "average the incoming rate over a long period of time" in order to infer a smoothed sample rate for use by the ASRC.)

But as clever and effective as that is, it is a totally unnecessary mechanism for asynch USB - where there is no incoming playback clock signal and hence no input jitter, period. Neither should there be. Computer audio systems should merely be data delivery systems. Basically they need to make sure the data arrives at the transceiver (the DAC) in a timely fashion and present a UI to the user for control...

Quote:

Originally Posted by EliasGwinn /img/forum/go_quote.gif You're talking about using I2S-type transmission...data with no clock.

Unless I'm mistaken I2S sends an explicit clock signal. But you're right - I am talking about data with no clock. On the other hand, the data stream has semantics, including an attribute specifying the playback sample rate the receiving device must use. As you pointed out this is done in electronic devices all the time:

Quote:

Originally Posted by EliasGwinn /img/forum/go_quote.gif The TAS1020B takes its cue from the incoming sample rate, adjusts its clock accordingly, and sends the data out at the native sample rate of the audio data.

Quote:

Originally Posted by EliasGwinn /img/forum/go_quote.gif This involves using large buffers, buffer management, and some sort of sample-rate information that could be usually obtained by reading SOF.

I'm not familiar with the acroynm "SOF", but buffer management is needed, although "large buffers" may not be for some value of large

(or more precisely, "large" depends on the requirements of your application). As dvse asserts, buffer management already takes place on the playback computer today. This is merely extending it to be ultimately controlled by the external DAC.

Quote:

Originally Posted by EliasGwinn /img/forum/go_quote.gif Ideally, every engineer would love to eliminate a problem without a downside. However, that scenario isn't really a 'tradeoff'. When a real tradeoff situation comes about, you must determine the best solution that acheives the most important objectives.

True, it's not a "tradeoff" as I stated it - apologies for abusing the term to make a point.

I think there may be actual tradeoffs here because the DAC1 has a broader set of use cases than a straight "asynch USB DAC", but the tradeoff is NOT about ASRC vs asynch mode USB. It's likely one or more of the following:

(1) You have built a product which does a really great job on input signals that have jitter. Why go to the expense of building and maintaining a second mechanism (for what might turn out to be a negligible or even entirely inaudible improvement) for one interface method?

(2) Asynch USB ideally relies on USB audio drivers built in to major OSes. Those (IIRC) don't support the highest sample rates and/or bit depths. You want to sell a product that does as far as possible...but don't really want to ship custom USB audio drivers.

(3) You need to support really low latency playback, and you can't achieve it with asynch USB because of the distributed buffer management.

I can understand any of these tradeoffs leading you to avoid asynch mode USB (although the second is pretty weak because it (presumably) applies to your existing USB support). But if you're only addressing use cases that can be supported by asynch USB mode, I've not seen any reason to use ASRC instead.

Cheers,
Mazz.