|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
65.19.76.104
In Reply to: RE: Windows or Apple for 2014/15? posted by Mercman on September 16, 2014 at 07:49:48
I read the manual. The description of clock circuitry and optimizations didn't make a lot of sense to me. It could be a poorly written manual, or perhaps it could be a design problem in the DAC's phase lock loop circuitry. Another curious thing is the implication that "Exact" mode will improve sound quality when on USB. Assuming the product implements asynchonous USB the only relevant clock is the local DAC clock, i.e. the clock mode should automatically be "exact" when on USB. (I note that with my DAC the choice of clock modes goes away when operating over USB as this is asynchonous.)
Did you try different clock modes over USB? Did they work? Was there a difference in sound quality? Did you try different computer optimizations or the lack thereof to see what the ill effects were?
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
Follow Ups:
In the past Auralic had its own ActiveUSB
ActiveUSB™
Resorting to the ActiveUSB™ technology from AURALiC, ARK MX+ overcomes the
transmission limitation from traditional Asynchronous USB which could only adjust +/-
one clock cycle error of data package in isochronous clock. With mass data buffer
technology and multi-stage, high resolution PLL circuit, ARK MX+ could buffer audio
stream as long as 2 seconds, which prevent time-based jitter resulted from the limitation
of computer.
You can find this in the ARX MX+ manual.
As there is no reference on their website to this technology anymore, they maybe dropped it.
In case of USB audio dropouts are a matter of a system with a high latency.
The protocol might be async but this of course won’t help if the response of the PC is to slow.
I’m surprised by their recommendation to switch to Win.
I don’t think this as by magic will improve things as there are Win systems with a very high latency.
In the past I had a HP Envy laptop. Plenty of power but the only way to get a decent latency was to disable both the WiFi and the NVDIA display driver.
As faith would have it, I had a Vega on loan at that time.
Indeed even with the ActiveUSB (buffering 2 seconds!) I had dropouts on this laptop using the Exact mode when playing highres.
Buffering for 2 seconds and having dropouts defies my logic and all I know about async USB.
The Well Tempered Computer
The buffer in an audio controller is a ring buffer. If an underrun occurs and the audio controller is not stopped, it will either keep repeating the sound contained in the buffer, which may hold a quarter of a second, or replace by silence depending on the implementation. Such effect is commonly referred to as "machinegun" or Max Headroom (character) stuttering effect.
What follows from the above, is that the stream that's buffered by DAC is already screwed up - there are already samples that don't belong there, or samples replaced by silence.
If you read the fragment you posted, they don't claim their technology has anything to do with dropouts problems - rather, it's intended to conquer jitter. Your guess is as good as mine how well that works out, but it is indeed irrelevant.
I'm not sure it's completely irrelevant. There is a control loop in either case that keeps the source and the sink in approximate synchronization, such that there are no buffer underruns at either end of the connection. The difference between SPDIF and async USB is which end is in control and how the feedback process works.
With SPDIF the computer is in control and the DAC must adjust. If it does a slow job of adjusting, its buffer will become exhausted. If it does a fast job of adjusting, it will adjust to jitter in the incoming signal, thereby degrading the audio quality. There are two ways to improve the situation: do a better job of predicting the average speed or use a large buffer. (If the buffer is large enough and is preloaded then there will be no need to adjust for an entire playlist, ...)
The best systems use a high order predictor and use rate information and buffer threshold to set strategy. Here the control loop is entirely in the DAC and under control of the DAC designer, the only unknown variable is the rate of the clock at the transport.
With Async USB the DAC is in charge. It controls the rate at which the computer sends data, but not the rate at which the computer sends frames. This means varying the number of samples per frame. There is some leeway for how to do this, but there is going to be a delay between when the requested number of frames is changed and when this takes effect in the returned frames. This requires sufficient buffering in the DAC to accommodate these delays. I suspect the logic to do this is probably implemented in firmware in the DAC and in software in the driver, but I don't know enough about O/S details to know how this is accomplished (e.g. at what interrupt level). This means that O/S latency can come into effect as well. In my experience, only the very best engineers can get these details correct, otherwise things "sort of" work.
There is a limit on the practical amount of buffering that can be used in the pipeline between the player application, driver, USB, USB cable, USB, and DAC proper (the part that gets an I2S stream). Not a matter of cost these days, but a matter of latency for end to end interaction, which depends on the application. A loose application allowing large delay is audiophile playback, where a lot of slop in the buffering just means that start, stop, skip forward, skip backward user interface operations are sluggish. With video playback there has to be audio video sync. For audio production work involving overdubbing or interactive audio (telephony or video conferencing) there is round trip delay and related human factors in perception of echos, etc... and the delay between application and analog audio must be small.
My main point is that this is very complicated and hard to get right. It need not affect overall sound quality. Sound quality will be affected by the size of the buffers, which determines the rate at which buffers have to be processed and the frequency of CPU loading. However, if multiple buffers are used to allow for rare delay circumstances then this won't affect the frequency of buffer loading. So there are actually two dimensions that can be adjusted, buffer size and number of buffers. Both of these may or may not be exposed via configuration windows.
At least in audio applications there are only two computers involved: transport and DAC. It gets far uglier when multiple computers get strung together and multiple clocks and multiple buffers have to be kept working in harmony.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
Another link, it sheds a bit op light on the buffering (page 2)
The Well Tempered Computer
In my case, the buffer size on the player side (Otachan ASIO plugin) is exposed, and is adjustable - not to mention that I can go into the program code, and screw it up to my heart's contect. This one, of course, has nothing to do with a particular DAC, and if set too low on a system with high latency, you'll get your stuttering no matter what is going on downstream.Whereas on the driver side (W4S ASIO driver) it is not exposed, so you're at the mercy of the driver developers, who hopefully did not set that buffer to extremely high size.
Edits: 09/19/14
With the USBPAL driver and ASIO interface to HQPlayer I have three parameters, the USB buffers, the ASIO buffers and the HQPlayer buffering. Also, there are two buffer error counters in the driver, one for USB and the other for ASIO. In addition, there is a third counter that can count up and this is buffering related, but it also is said to relate to data errors on the USB. I suspect this relates to the signaling back from the DAC to the driver, but exactly how is not clear.
One thing I have noticed is that if I set the USB buffers to the minimum and overload the computer there will be lots of errors showing up in the counters, but most of these are inaudible. On the other hand, increasing the USB buffers to the maximum results in few errors (even if the computer is grossly overloaded) but when they hit they are highly audible. Best sound comes with a small set of USB buffers and taking care not to overload the computer. The sonic effect of other parameters is less obvious.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
Thanks for the link.
It looks like the manual could have used a better quality translation into English. Or maybe the scheme didn't work so well. It's a very hard problem to get right. It's even difficult coming up with a consistent notation and model that takes into account the relevant factors, such as differences in clock frequency, drift over time/temp/voltage/age of clock frequency and phase jitter.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
Another curious thing is the implication that "Exact" mode will improve sound quality when on USB.
Possibly but does it trump a DAC with an atomic clock but lacking "Exact" mode? ;-) This is more ridiculousness in marketing for the audiophile market, IMHO.
I have no experience with this DAC, but have looked at what the manufacturer recommends and my friends who own this DAC have done. I agree with you Tony that this tweaking should not be necessary.
A more powerful computer? I need first hand experience with this DAC. Something that is not going to happen anytime soon.
Post a Followup:
FAQ |
Post a Message! |
Forgot Password? |
|
||||||||||||||
|
This post is made possible by the generous support of people like you and our sponsors: