It is an issue in pure synchronous mode when the DAC is clocked from USB clock, but I don't think any reasonable DACs use this approach these days.
DAC Newbie. Help!
- Thread starter rromeo
- Start date
It is an issue in pure synchronous mode when the DAC is clocked from USB clock, but I don't think any reasonable DACs use this approach these days.
JoeESP9
ESL's & tubes since 83
Please educate me. What does that have to do with the question of a USB signal being analog or digital?
With synchronous transmission the source clock is used. With asynchronous transmission the destination clock is used. There is nothing analog involved.
The physical signal on the wire is analog and as such is subject to degradation depending on the quality/length of the cable leading to sloping of fronts and trails, in addition to the typical imprecise clock of the source this sloping creates an additional uncertainty for clock recovery i.e. increased jitter. That's why pure synchronous USB mode is pretty much never used for DA conversion now. Adaptive and asynchronous mode avoids this issue by having a stable clock on the DAC itself. Adaptive mode can in theory lead so some sample loss, asynchronous should in theory be bit-perfect.
JoeESP9
ESL's & tubes since 83
I give up. Please do some research.
The signal on a USB output prior to the DAC is considered to be digital as it consists of "rounded off" square waves. Although the voltage change is analog (all voltage changes are analog) that doesn't make them an analog signal. I strongly suggest you take a look at analog and digital audio signals on an O'Scope. It may be quite enlightening.
The signal on a USB output prior to the DAC is considered to be digital as it consists of "rounded off" square waves. Although the voltage change is analog (all voltage changes are analog) that doesn't make them an analog signal. I strongly suggest you take a look at analog and digital audio signals on an O'Scope. It may be quite enlightening.
Last edited:
I've looked at enough signals on O'Scope during my life, I don't need any schooling on that. It is the quality of transitions that is important for clock recovery, that is if the clock was precise in the first place. If you can't do that the analog voltage past the DAC won't be in the right place in time. So cables can make all sorts of differences for SQ in pure synchronous mode. But as we determined it is not used in modern DACs, so this argument remains just a theoretical exercise.
Markoneswift
Quartz locked n ready to rock
I think I will stick to CDs.
JoeESP9
ESL's & tubes since 83
This is a digital audio waveform. as viewed on a scope.
This is an analog audio waveform as viewed on a scope..
This is how they look on an O'Scope.
There is no analog component to a digital audio signal other than the change in voltage which by definition has to be analog.
FWIW: With an asynchronous USB connection the receiving device handles the clock. Thanks to Gordon Rankin of Wavelength Audio for inventing asynchronous USB data transmission.
This is an analog audio waveform as viewed on a scope..
This is how they look on an O'Scope.
There is no analog component to a digital audio signal other than the change in voltage which by definition has to be analog.
FWIW: With an asynchronous USB connection the receiving device handles the clock. Thanks to Gordon Rankin of Wavelength Audio for inventing asynchronous USB data transmission.
Last edited:
There isn't a lack of pretty pictures on the Internet. Welcome to reality. You can find some sample images of what actual waveforms look like here: https://electronics.stackexchange.c...he-source-of-this-shape-on-my-usb-eye-diagram
Sloping fronts are the "analog" artifacts present in digital signal that increase the uncertainty of transition detection making precise clock recovery, which is very important for digital audio, difficult. It has no effect when you send a print job to your printer but digital audio is different. This is why we need asynchronous USB and such, and while it is digital it is not all about 0's and 1s'. If you don't get it I can't help.
JoeESP9
ESL's & tubes since 83
Asynchronous USB transmission means that the clock in the receiving device is used for timing. It doesn't mean anything else. The actual shape of the "square wave" is irrelevant as long as there is enough definition in the signal for a given DAC to read the signal as digital.
Sloping fronts are not an analog component of the signal. They are inadequacies in the rise time of the electronics. The same applies to sloping tops and sloping ends. Sloping ends are directly related to the slew rate of the circuit.
If you're curious I suggest you check out the Wavelength Audio web site as Gordon Rankin (the owner and designer for Wavelength Audio) is the man who invented asynchronous USB data transmission. He also wrote the first code for it.
Sloping fronts are not an analog component of the signal. They are inadequacies in the rise time of the electronics. The same applies to sloping tops and sloping ends. Sloping ends are directly related to the slew rate of the circuit.
If you're curious I suggest you check out the Wavelength Audio web site as Gordon Rankin (the owner and designer for Wavelength Audio) is the man who invented asynchronous USB data transmission. He also wrote the first code for it.
Last edited:
It is irrelevant as long as the DAC has internal stable clock and a good reclocker.
Huh? Asynchronous data transfers are discussed in the USB spec so while he may have been one of the first who applied these principles to DAC USB interfaces he most certainly did not invent it.
I wound up buying a Surface Pro 3 with a cracked screen that still works great but touch screen doesn't work for cheap.
Put the free Windows 10 upgrade on it.
Hooked up USB hub - USB audio with optical out feeding DAC.
Run my music off USB memory stick filled with FLAC songs.
Sounds good with no fan noise.
Put the free Windows 10 upgrade on it.
Hooked up USB hub - USB audio with optical out feeding DAC.
Run my music off USB memory stick filled with FLAC songs.
Sounds good with no fan noise.
adri2000
New Member
I do not recommend use tablet or laptop as music player. All parts (CPU, RAM, USB controllers) are squeezed in small space and from my experience that always will have bad effect on digital signal quality. PSU is also a compromise.
Better use older small form PC with good quality PSU. SSD is a must, HDD drives keep farther away (in server or NAS). Also RAM quality (speed, latency) have effect on sound.
Better use older small form PC with good quality PSU. SSD is a must, HDD drives keep farther away (in server or NAS). Also RAM quality (speed, latency) have effect on sound.
Last edited:
I read in a discussion on Comupteraudio that a HDD is just like a CD but the rpm is higher... that same source also dissed SSD and stated that a USB stick is the way to go... I don't remember the reasoning sorry.
I have a Raspberry pi (2b i think - this has no built in wifi - one less potential source of RF nosie) which i got for 35 bucks and hardwired it to my router. I use the the Ifi Audio power supply ( https://www.bhphotovideo.com/c/product/1275641-REG/ifi_audio_0306007_5v_ipower_5v_for_all.html ) to feed the Raspberry based on recommendation I found on computeraudio forums. I added a 256 Gb USB stick with my music and just for the fun of it I duplicated that library to an HDD which I connected to the router's USB port. The Raspberry can map that as an external network drive. I did this to see if there was any difference in the SQ between the stick and the HDD on my system. I can't hear any but I'm not a seasoned audiophile so YMMV...
The raspberry is running RuneAudio build and I can use MPDroid on my cell or any computer/tablet connected to the same router to remote control it. It is feeding a Topping D30 ($99) through an (async) USB connection.
I'm very very happy with the SQ.
I also tried a beaten up old Laptop with JRiver and foobar but I had issues with drivers as that thing would not take win10 and the Vista drivers were giving me hell...
My solution is cheap enough for anybody to try (people spend more on interconnects..). I'm dying to try a high pricetag DAC to see how it would improve the SQ but can't make myself spend a grand on that only to find out I can't hear any difference...
I have a Raspberry pi (2b i think - this has no built in wifi - one less potential source of RF nosie) which i got for 35 bucks and hardwired it to my router. I use the the Ifi Audio power supply ( https://www.bhphotovideo.com/c/product/1275641-REG/ifi_audio_0306007_5v_ipower_5v_for_all.html ) to feed the Raspberry based on recommendation I found on computeraudio forums. I added a 256 Gb USB stick with my music and just for the fun of it I duplicated that library to an HDD which I connected to the router's USB port. The Raspberry can map that as an external network drive. I did this to see if there was any difference in the SQ between the stick and the HDD on my system. I can't hear any but I'm not a seasoned audiophile so YMMV...
The raspberry is running RuneAudio build and I can use MPDroid on my cell or any computer/tablet connected to the same router to remote control it. It is feeding a Topping D30 ($99) through an (async) USB connection.
I'm very very happy with the SQ.
I also tried a beaten up old Laptop with JRiver and foobar but I had issues with drivers as that thing would not take win10 and the Vista drivers were giving me hell...
My solution is cheap enough for anybody to try (people spend more on interconnects..). I'm dying to try a high pricetag DAC to see how it would improve the SQ but can't make myself spend a grand on that only to find out I can't hear any difference...
cpt_paranoia
Addicted Member
Unless you are using the analogue output from a device, the digital processing will have little bearing on the sound, provided there is adequate processing and memory to ensure an uninterrupted stream of data. RAM speed and latency can only have an effect on processing speed, nothing else.
If you are using a USB or coax S/PDIF interface to a DAC, there is a small possibility that conducted noise might get into the DAC audio, but a well-designed DAC should provide effective isolation of the input.
If you are using an optical S/PDIF interface, there is no electrical path to conduct noise from PC to DAC via the signal path; it would have to be radiated from PC to DAC, or conducted via the mains supply. If you provide a sensible physical separation, and the DAC is adequately protected against radiated and conducted susceptibility, you should not have problems.
The last mechanism by which noise might be passed to the DAC is due to jitter in the signal timing of the USB or S/PDIF. Such jitter should be removed by the clock recovery, data sampling & FIFO buffer in the DAC. It is the sample clock to the DAC chip that determines the DAC sample timing, not the digital input stream. This DAC sample clock should be provided by a low phase noise source, such as a crystal oscillator.
The fact that there is no flow control between source and destination in the simple protocols means that it is possible for data overflow or underflow to occur, due to the use of different oscillators at each end; data is sent at one rate by the source, and consumed at a different rate at the DAC. But this will be mostly dealt with by use of a FIFO buffer in the DAC, and the fact that crystal oscillators have a pretty good tolerance. Data overflow or underflow would result in a missed sample, or a duplicated sample; for instance, the VoIP protocol provides a mechanism to drop, or repeat frames as necessary, since the source and destination clock rates may be more significantly different.
If you are using an analogue output from a PC, laptop or tablet, you might consider using a lead fitted with an RF suppressing filter, to prevent RF noise being conducted along the signal cable. The audio circuits should also be designed such that they will not respond to RF, usually by a simple low-pass filter on the signal input. They should also be designed to prevent radiated susceptibility, preventing RF injection into the circuit.
RF injection can cause problems if it hits a rectifying element in the design, which will perform amplitude demodulation to baseband (audio frequencies), the classic being mobile phone injection (GSM will give a 216.6Hz buzz due to the TDMA frame rate), or even more classic; dental fillings that receive radio stations...
If you are using WiFi or Ethernet streaming, there is almost no chance of conducted noise from the 'player' computer; the media stream is transported as a CODEC format, and reconstructed by the DMR. A badly designed DMR might be susceptible to WiFi or Ethernet noise, and noise generated by the processor performing the rendering.
If you are using a USB or coax S/PDIF interface to a DAC, there is a small possibility that conducted noise might get into the DAC audio, but a well-designed DAC should provide effective isolation of the input.
If you are using an optical S/PDIF interface, there is no electrical path to conduct noise from PC to DAC via the signal path; it would have to be radiated from PC to DAC, or conducted via the mains supply. If you provide a sensible physical separation, and the DAC is adequately protected against radiated and conducted susceptibility, you should not have problems.
The last mechanism by which noise might be passed to the DAC is due to jitter in the signal timing of the USB or S/PDIF. Such jitter should be removed by the clock recovery, data sampling & FIFO buffer in the DAC. It is the sample clock to the DAC chip that determines the DAC sample timing, not the digital input stream. This DAC sample clock should be provided by a low phase noise source, such as a crystal oscillator.
The fact that there is no flow control between source and destination in the simple protocols means that it is possible for data overflow or underflow to occur, due to the use of different oscillators at each end; data is sent at one rate by the source, and consumed at a different rate at the DAC. But this will be mostly dealt with by use of a FIFO buffer in the DAC, and the fact that crystal oscillators have a pretty good tolerance. Data overflow or underflow would result in a missed sample, or a duplicated sample; for instance, the VoIP protocol provides a mechanism to drop, or repeat frames as necessary, since the source and destination clock rates may be more significantly different.
If you are using an analogue output from a PC, laptop or tablet, you might consider using a lead fitted with an RF suppressing filter, to prevent RF noise being conducted along the signal cable. The audio circuits should also be designed such that they will not respond to RF, usually by a simple low-pass filter on the signal input. They should also be designed to prevent radiated susceptibility, preventing RF injection into the circuit.
RF injection can cause problems if it hits a rectifying element in the design, which will perform amplitude demodulation to baseband (audio frequencies), the classic being mobile phone injection (GSM will give a 216.6Hz buzz due to the TDMA frame rate), or even more classic; dental fillings that receive radio stations...
If you are using WiFi or Ethernet streaming, there is almost no chance of conducted noise from the 'player' computer; the media stream is transported as a CODEC format, and reconstructed by the DMR. A badly designed DMR might be susceptible to WiFi or Ethernet noise, and noise generated by the processor performing the rendering.
cpt_paranoia
Addicted Member
Timing error on the USB is immaterial; it does not propagate to the DAC sample clock.
Femtoseconds is pushing it... it will be in picoseconds (USB3 being 5Gb/S, so 200ps period).
JoeESP9
ESL's & tubes since 83
Every DAC that operates asynchronously has a fairly decent internal clock.
Okay, lets agree that he wrote the first code that can do that. (IIRC he got a patent for it). It's an indisputable fact Wavelength Audio DAC's were the first commercially available DAC's to operate asynchronously via the USB port.
cpt_paranoia
Addicted Member
Any system where the source and destination are not clocked by the same clock are 'asynchronous', although in this context, more accurately described as plesisochronous. The concept has been around for a very long time, and is in use practically everywhere where source and destination cannot be perfectly synchronous, because there is no direct clock connection.
I don't know when the patent was granted, but I do know that the patent process is a rubber-stamping 'sort it out in court' process at the moment, with no real assessment of prior art or merit of the claim.
I don't know when the patent was granted, but I do know that the patent process is a rubber-stamping 'sort it out in court' process at the moment, with no real assessment of prior art or merit of the claim.
