|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
50.159.77.150
In Reply to: RE: John Swenson on Sata cables posted by Tony Lauck on July 10, 2014 at 08:30:16
"I don't see how reducing noise a little in the computer system is going to reduce the error rate (bit error rate) on a USB cable"
I don't either for cases of well implemented usb.
"The problem with computer audio is noise being transferred from the electrically noisy computer to the critical analog components of the playback chain, starting with the master clock that controls the timing of digital to analog conversion and working downstream from there toward the speakers."
I believe you are correct if there are no errors in the data. In that case the bad sound must be a noise immunity problem in the downstream hardware whether it is in the usb signal to dac ready data reconstruction process (depending on DAC type), DAC clocking circuit or the analog sections.
"Most of the USB errors that people get are timing errors, because USB audio is streamed in real time. These can be minimized by reducing competition for computing resources (latency) or by increasing buffer sizes. "
What kind of modern computer can't keep up with measly audio data rates? This whole concept sounds suspect for an asynchronous usb transfer. Is your Mytek capable of receiving asynchronous transfers?
Follow Ups:
The Mytek is said to use asynchonous USB timing, but this is according to marketing literature and I don't have the tools or technical documentation to independently verify this. The Mytek uses a proprietary driver and FPGA receiver from Rigisystems. It seems likely this has quirks that even the Mytek designer is not aware of.
Commercial off the shelf operating systems (COTS) such as Windows are not designed for real-time operation. Unless specially modified or stripped down they have a tendency to go off and do their own thing, sometimes for seconds at a time. While at least CD quality audio was possible with computers 20 years ago and today's computers are 1000's of times faster, the extra performance hasn't materialized into higher real-time performance for various reasons, most likely because of software bloat that remains acceptable for "normal" use. However, even if the software bloat has been excised by custom modifications operation can still be marginal when small buffer sizes favored by audiophiles are used, imposing real time requirements in the 1 msec range. Over the years, processor/os interrupt response has not scaled with increasing CPU clock speeds for various reasons having to do with the evolution of processor technology, operating system technology, and the marketplace.
It is also possible to use these "fast" CPUs to do DSP functions that completely exhaust their capability. This includes things like 1 second convolution of audio samples at 5.6 Mhz, as would be needed to do digital room correction in the bass on a DSD128 file without downsampling. I do this successfully at DSD64, but this uses a substantial fraction of available processing power.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
"I do this successfully at DSD64, but this uses a substantial fraction of available processing power."
Cool, seems like the perfect app for multi core processing assuming there are convolvers capable of utilizing it.
Main problem I have is that the computation causes the CPU fan to speed up from 1300 RPM to 2000 RPM and become audible.
HQPlayer has a convolution engine that uses all available cores.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
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: