WAV vs FLAC revisited
- Thread starter Vincent Kars
- Start date
There are quite a good number of DACs ith Asynchronous USB : From very little money and good .. HT Streamer DAC at ($149) to to lot of money and still good
dCS Paganini DAC (around $20,000/ ..As best I can figure out, Async USB is licensed or is extra work to develop on their own relative to just buying the standard ones.
XMOS is often used for the async receiver.
http://www.thewelltemperedcomputer.com/HW/USB_DAC_Async.htm
http://www.thewelltemperedcomputer.com/HW/USB_DAC_Async.htm
amirm,
Buffering is *everything*. There are literally hundreds of buffers utilized in an operating system to facilitate stable communications between unlike devices.
The audio clock (not necessarily the DAC) is *always* the master, regardless of the source, as far as digital audio is concerned. Networks, fileservers, any other source simply provide a stream of data (they usually don't even know or care what it is) to the requesting machine. And buffering plays an important role every step of the way.
In the case where the source data stream is slower than the clock rate (seen mostly over limited bandwidth internet connections) the local system (the requesting system) will buffer the stream into a temporary disk file until it reaches a certain size (set by the application software) at which point it will start delivering a stream of data to the audio device buffer. When that buffer is full the device software will start delivering it bit by bit at the clock rate to the device. While this is going on, the incoming stream is still adding to its buffer and the OS is delivering contents of the stream buffer/temp disk file to the audio device buffer as is needed. If and when the well runs dry (inbound buffers are empty or below a preset threshold), audio stops until the buffers catch up. It is *entirely* the OS's responsibility to manage this interchange transparently between the various buffers involved.
If the source data stream is faster than the audio clock, it will be buffered to a temporary disk file, which in turn dispenses it to the audio device buffer as quickly as the audio device can accept it.
The two examples above assume real time streaming. If it's not real time, the source stream will be saved in its entirety before any audio is processed (download and save). When it is processed, it is by opening the saved file and reading bits according to the audio clock rate, again from the disk file buffer, to the audio device buffer and then to the device at the clock speed.
A source is *never* the master clock of anything, it's just a delivery method. The local system (to which the stream is being delivered) is responsible for managing the data in a meaningful way.
The same procedure happens with video and with video+audio. With video+audio the two are multiplexed together in one stream and separated in the playing application, so other than slight synchronization differences due to demuxing, decoding or subsequent video processing, they start out in sync at the receiving computer.
If all of what I have (quite simplistically) described doesn't happen, streaming audio or video would be virtually impossible.
Also, when you are accessing an audio or video file on a local hard disk or NAS, the source (in this case the disk i/o system) is most always going to be much faster than the audio/video clocking, so it will only be read from the disk in small buffer fulls as needed. You can see the effects of this by watching a disk activity monitor while listening to audio files or watching video files, or watching a network bitrate monitor when doing the same over the internet.
I hope this helps with understanding the processes involved.
--Bill
I’m afraid a lot of your arguments are not related to the problem.
PCM=sample + time step
Each times time step should be of equal length.
As the time step is generated by a clock this is of course impossible, in our physical world there ain’t such thing as infinite precision.
Ok, we want this time step as close to perfection as possible.
One of the tricks to obtain this is, beside using a clock with a very low intrinsic jitter, is to avoid input jitter.
Whatever your source is, be it streaming, be it a file on a HD, the data is pre-fetched and stored in memory.
The data is decoded and then send to the audio device.
All what happens before this is irrelevant from a jitter perspective.
Sending the audio (lpcm most of the time) to a DAC is a matter of a protocol.
SPDIF is a real time stream, the bitrate is used to construct the sample rate.
It is a unidirectional protocol. As a consequence, on protocol level there is no way the receiver can influence the sender.
In principle the input jitter is as low or as high as the quality of the clock of the sender dictates.
In practice there are all kind of trick applied to reduce the input jitter like PLL, ASRC, FIFO, etc but we probably talk about reducing, not to be mistaken for eliminating input jitter.
Adaptive USB is pretty much like SPDIF, unidirectional and in this case the sample rate is derived from the data rate.
You might (and will buffer) but buffer management is and can only be done by the DAC by varying the clock speed to avoid under/over run.
This applies to SPDIF as well, if there is no feedback loop only varying the clock speed will help.
Async USB is bi-directional, here you have the option to vary the data rate so now the DAC can run at fixed speed.
This link demonstrates the difference between an adaptive mode (buffered of course) and a async mode (buffered of course) nicely:
http://www.audiomisc.co.uk/Linux/Sound3/TimeForChange.html
PCM=sample + time step
Each times time step should be of equal length.
As the time step is generated by a clock this is of course impossible, in our physical world there ain’t such thing as infinite precision.
Ok, we want this time step as close to perfection as possible.
One of the tricks to obtain this is, beside using a clock with a very low intrinsic jitter, is to avoid input jitter.
Whatever your source is, be it streaming, be it a file on a HD, the data is pre-fetched and stored in memory.
The data is decoded and then send to the audio device.
All what happens before this is irrelevant from a jitter perspective.
Sending the audio (lpcm most of the time) to a DAC is a matter of a protocol.
SPDIF is a real time stream, the bitrate is used to construct the sample rate.
It is a unidirectional protocol. As a consequence, on protocol level there is no way the receiver can influence the sender.
In principle the input jitter is as low or as high as the quality of the clock of the sender dictates.
In practice there are all kind of trick applied to reduce the input jitter like PLL, ASRC, FIFO, etc but we probably talk about reducing, not to be mistaken for eliminating input jitter.
Adaptive USB is pretty much like SPDIF, unidirectional and in this case the sample rate is derived from the data rate.
You might (and will buffer) but buffer management is and can only be done by the DAC by varying the clock speed to avoid under/over run.
This applies to SPDIF as well, if there is no feedback loop only varying the clock speed will help.
Async USB is bi-directional, here you have the option to vary the data rate so now the DAC can run at fixed speed.
This link demonstrates the difference between an adaptive mode (buffered of course) and a async mode (buffered of course) nicely:
http://www.audiomisc.co.uk/Linux/Sound3/TimeForChange.html
There are quite a good number of DACs ith Asynchronous USB : From very little money and good .. HT Streamer DAC at ($149) to to lot of money and still good
FrantzM,
Just wanting to know those models whose sound quality does not depend on the computer activity, file type, type of music server, computer , operating system, cables or other gimmicks ...
And all I get are general vague answers. Frantz,
Does this mean you never dreamed (or owned ) the great sounding Burmester 979 Transport?
Thanks Vincent, I had completely missed the 'external USB DAC' concept and approached it from an internal computer-centric to outside world view.I’m afraid a lot of your arguments are not related to the problem.
PCM=sample + time step
Each times time step should be of equal length.
As the time step is generated by a clock this is of course impossible, in our physical world there ain’t such thing as infinite precision.
Ok, we want this time step as close to perfection as possible.
One of the tricks to obtain this is, beside using a clock with a very low intrinsic jitter, is to avoid input jitter.
Whatever your source is, be it streaming, be it a file on a HD, the data is pre-fetched and stored in memory.
The data is decoded and then send to the audio device.
All what happens before this is irrelevant from a jitter perspective.
Sending the audio (lpcm most of the time) to a DAC is a matter of a protocol.
SPDIF is a real time stream, the bitrate is used to construct the sample rate.
It is a unidirectional protocol. As a consequence, on protocol level there is no way the receiver can influence the sender.
In principle the input jitter is as low or as high as the quality of the clock of the sender dictates.
In practice there are all kind of trick applied to reduce the input jitter like PLL, ASRC, FIFO, etc but we probably talk about reducing, not to be mistaken for eliminating input jitter.
Adaptive USB is pretty much like SPDIF, unidirectional and in this case the sample rate is derived from the data rate.
You might (and will buffer) but buffer management is and can only be done by the DAC by varying the clock speed to avoid under/over run.
This applies to SPDIF as well, if there is no feedback loop only varying the clock speed will help.
Async USB is bi-directional, here you have the option to vary the data rate so now the DAC can run at fixed speed.
This link demonstrates the difference between an adaptive mode (buffered of course) and a async mode (buffered of course) nicely:
http://www.audiomisc.co.uk/Linux/Sound3/TimeForChange.html
Internal audio devices or external firewire audio devices both have OS drivers which can communicate to the hardware ports of the audio device... sort of a back channel. Not quite bidirectional, but similar capabilities can be performed.
But I personally have a hard time believing that control of the bit rate of the s/pdif output signal over a USB port (to the Halide or other async device) is capable, by drivers and timing controlled by the PC CPU, even if paced by the async device, to exactly match the internal clock rate of the Halide device predictably and consistently.
Especially with many USB controllers and other devices in the driver tree. Maybe there are limitations, like no other devices present on a particular root USB controller to which the asynch audio device is connected, or no external HD's allowed ... something like that?
Whether there really would be an improvement in the resulting audio from a jitter standpoint would depend entirely on the accuracy and stability of the Halide's internal clock(s). Do we know those are of truly professional accuracy?
I think I'll get one of these and take a listen. Too bad there's no 176k or 192k support, though.
--Bill
The moment USB switches to isochronous mode, there is a guaranteed bandwidth on the bus
(not to be mistaken for guaranteed bandwidth, this says nothing about what is happening upstream).
If needed you can check the PC for a non-shared hub:
http://thewelltemperedcomputer.com/SW/Windows/Win7/USBDAC.htm
USB audio in more detail can be found on my website: http://thewelltemperedcomputer.com/KB/USB.html
If you want to know “everything”
http://www.beyondlogic.org/usbnutshell/usb1.shtml
http://www.tech-pro.net/intro_usb.html
USB audio class 1 is more or less tied to USB 1. This limits the audio to 2 ch 24/96
In 2009 USB audio class 2 standard was finalized.
As it uses USB 2 high speed, any sample rate will do.
From mid 2010 OSX and Linux comes with native mode class 2 drivers.
This explains why the number of converters and DAC > 96 kHz is small.
But almost all new models now feature async USB and USB class audio 2.
Most of them use the XMOS receiver. In general a driver for Win is supplied too (Thesycon)
Some examples can be found here:
http://thewelltemperedcomputer.com/HW/USB_Audio.htm
http://www.digitalaudioblog.com/
(not to be mistaken for guaranteed bandwidth, this says nothing about what is happening upstream).
If needed you can check the PC for a non-shared hub:
http://thewelltemperedcomputer.com/SW/Windows/Win7/USBDAC.htm
USB audio in more detail can be found on my website: http://thewelltemperedcomputer.com/KB/USB.html
If you want to know “everything”
http://www.beyondlogic.org/usbnutshell/usb1.shtml
http://www.tech-pro.net/intro_usb.html
USB audio class 1 is more or less tied to USB 1. This limits the audio to 2 ch 24/96
In 2009 USB audio class 2 standard was finalized.
As it uses USB 2 high speed, any sample rate will do.
From mid 2010 OSX and Linux comes with native mode class 2 drivers.
This explains why the number of converters and DAC > 96 kHz is small.
But almost all new models now feature async USB and USB class audio 2.
Most of them use the XMOS receiver. In general a driver for Win is supplied too (Thesycon)
Some examples can be found here:
http://thewelltemperedcomputer.com/HW/USB_Audio.htm
http://www.digitalaudioblog.com/
dreamed and owned ... This aticular transport and its asociated DAC had a synch cable and there was a difference when using the Synch cable .. Obvious but really subtleFrantz,
Does this mean you never dreamed (or owned ) the great sounding Burmester 979 Transport?
As Vincent mentioned, you cannot perform the same function. Since the S/PDIF source is a master, it doesn't need to comply with anything external to it architecturally anyway.
Well, the answer is what you gave: buffering! The PC in this scenario becomes a data pump just like your hard disk is when you play internally to the PC. The async adapter buffers enough data to play and once its buffer gets below the "low watermark" (i.e. a point where there is need for more data but that we are not going to run dry if it doesn't come immediately), it will request the next chunk of data from your PC.
Of course, there is no guarantee that the PC will respond in time. If it doesn't you will get an audio glitch. Same thing happens when the PC is in charge and your media player or the OS/hard disk fall behind in reading the data to feed the DAC. Shifting the point of control externally doesn't make this problem any worse.
Fortunately the amount of data we need to read to play music is very small relative to the kind of capabilities we have in PCs these days. If you run a PC as a dedicated music server and especially if you put your music on SSD, you will get reliable playback as a practical matter.
If you have a lot of traffic on that USB port, yes, you can run out of bandwidth or get hit with high latency and get a glitch. The answer is, "don't do that."
Good USB adapters will have fair bit of buffering and reduce or eliminate the chances of this happening. I worked with Lee to debug a problem he had with his USB adapter that was glitching. The problem was the visualizations in his music player on the PC that was using too much CPU cycles causing it to fall behind. The software company was notified and they fixed it.
Sadly few companies publish such data. One of them that does is Audiophilleo. And for Halide, we have measurements performed in stereophile review. Here is a comparison of using Toslink out of a pro audio card, RME, on the PC running an external DAC relative to Halide. First the Toslink:
Ideally we would have just that center 11 Khz tone there and nothing else. The extra pulses are created by high levels of jitter despite the device producing it being a pro sound card with its drivers, buffering and such.
Now the Halide driving the same DAC using async USB:
As you see, the level and number of jitter sidebands is heavily reduced and now well below the CD's 16-bit noise floor. With better DACs than this cheap one, it still makes a difference and produces extremely clean output. I believe this is a good representative of other async adapters since this is one of the lower cost units.
So the evidence does point to improvements there and in a compelling way.
There are other async adapters that support higher sampling rates. You just need a driver in the PC. I use Audiophilleo and Berkeley alpha USB to S/PDIF & AES both of which support up to 192 KHz. I just wrote this article on topic of audio jitter that may be a good read in this area. And a bit of information about the Berkeley here: http://www.whatsbestforum.com/showthread.php?4160-Review-Berkeley-Audio-Alpha-USB
It seems this subtle difference was worth the usd 15000 ...
The first system using this type of sync cable that I have listened to was the Sony CDP-R1 and DAS-R1 in the late 80s, more than twenty years ago. Unhappily this system was quickly abandoned in favor of fancy systems relying on recovering the transport clock.
Many times I though about modifying a good DAC and a cheap CD transport fitting them with such a link, but never had the time.
http://www.thevintageknob.org/sony-CDP-R1.html
Attachments
garylkoh
WBF Technical Expert (Speakers & Audio Equipment)
If you're just buying one to try, the M2Tech Evo is the best value for money I know and works up to 24/192:
http://www.m2tech.biz/evo.html
The M2Tech Young is a DAC that is <$1,800 and goes up to 24/384. At this point, it's the best value DAC I know (and one of the best irregardless of price).
It's a little bizarre that often a technical solution to something is called a kludge or trick, just because it matter of factly solves a "problem" or lack of precision: it's as if the "correct", blessed solution is the only one that's truly valid, and all others are pretenders. If engineering or innovative thinking always had to achieve real results using that mindset in other areas we would still be arguing the validity of the wheel as a way of moving things, because it would "too hard" to create a perfectly round one ...
Frank
Frank
I looked at the M2Tech Evo, but found the wording of their description of how it works a little odd. They don't seem to come right out and say they're using the USB Async mode, and elsewhere in their text they use the term 'reclock'.
I also ran across the Mapleshade unit, which by description is a reclocking conditioner. It looks strangely similar to the M2Tech Evo, except with a wood body, but that could be coincidence. It's only $189. One has to wonder (as I do with many of their offerings).
Amir mentioned two others to possibly try as well, but I have already made the purchase of the Halide, so will at least give that a try compared to my current audio chain to see how it stacks up. My DAC is my monitor controller for the studio, a Crane Song Avocet which is primarily used in professional audio apps for studios and mastering facilities. I probably will not be changing that any time soon.
--Bill
I will perform an empirical validation between FLAC and WAV hopefully today, since I have just downloaded a cd-ripper that will allow me to copy my CD collection to the Mach2 server, which already has access to previously ripped CD files in WAV format - I will post my findings.
Bill Demars
Well-Known Member
I have found that decoding a flac file to wav has improved the sound substantially. I use flacfrondend to open the flac file and then choose to decode the file to wav. Much more air and a more open sound.
Similar threads
