[NZtechfreak]

I use the "site:" search in Google a lot. Nice tip for those unaware!

 

[kokushu]

Is there a usb otg cable that I could use that I don't need the adapter cable first?  I prefer it to end in usb b since that is what my dac/amp allow right now.

 

[Consutancy]

Thank you for the excellent post, however there are some things that are not quite right and might be causing you a little misunderstanding? The main ones are.
 
"it's arguably impossible to have bit perfect playback in a real-time system"
 
I must be misunderstanding you?  Computers all have bit perfect playback in real time.  Any errors in the bits have to be corrected in real time, or .zip files would always be corrupted, the numbers on bank accounts would be way off and so on.
 
"Because audio is real time, there is no error correction that can be done to this square wave, any resulting wave form IS your music."
 
This is not quite right, look up hysteresis loops as commonly used on input gates on digital logic, they "condition" the output levels and rise/fall times.  Used with the clock pulses, the width of the output pulses are synced with the clock pulses to produce output pules that are of the correct width and timing.
 
"Jitter is an alteration of the duty cycle"
 
No, it is an alteration of the timing.  The pulse can be the same width, but delayed for example  - The rising edge and the falling edge being delayed by the same amount.  The pulse is still within normal parameters, just delayed.
 
"a DAC for instance, that jitter is seen as an amplitude error and creates an alteration of the frequency response."
 
I am sorry, but it does not.  Most DACs convert at least 8 bits at a time, each bit is fed to a separate input pin of the DAC by a clock pulse, the DAC effectively waiting for the pulse to arrive for the whole time of the clock pulse.  That can conceivably result in a high-to-low transition or low-to-high transition arriving during the input cycle and that is why you sort out and timing problems ahead of it.  It is done all the time in computers and all digital circuits where it can be a problem.  It is part of the trouble-shooting of circuits and why I have specialist oscilloscopes with 8 inputs for finding where any timing discrepancies are creeping in(AKA logic analyzers).  Digital circuits would not work with jitter causing errors, computers would be impossible with error bits all over, so jitter can be reduced to no-error levels, even at hundreds of MHz.  I noticed in the article you linked to, he is concerned with reducing the jitter to improve the specs, not because it is causing a problem
 
For example - In the example you give of jitter causing problems, he sorted it out, even though it was a delay of just 358ps, which translates to a frequency of a little over 2.793GHz for a delay of a whole pulse.  Which is why jitter is important in computer circuits, but massively less of a problem with circuits working for audio.  Even the fastest digital circuitry associated with the actual audio signal is working at < 100MHz for even the highest quality (say a sampling rate of 384000Hz x 24 bits x 2 for Nyquist = 18.432Mhz BUT good rise times typically require at least the fifth harmonic, so = 92.16Mhz bandwidth requirement).  Jitter might be important there you might consider, but it is not, because it is already allowed for in the Nyquist frequency choice and the fifth harmonic.  Jitter on a pulse could affect the rise time, but it gets corrected by the circuits.  You can feed a sine wave into a hysteresis loop and get a square wave out, that is how good they are. I have tried to keep this as simple as possible, but where stubborn problems remain, more sophisticated circuits are used to correct jitter, like PLLs, and are another safeguard.  Any digital system has all the time-sensitive parts of it running from a single clock to reduce jitter further - Think of genlock in professional video gear to keep all cameras and processing equipment locked to exactly the same frequency and instant.
 
There are quite a few others, but you should be able to sort them out when you sort out the ones I've mentioned.

 

[StanD]

The jitter bugs will not be convinced. Everytime I ask someone that proclaims picoseconds and femtoclocks, "How many ppm or ps is required to affect audio and in what manner", I never get a reply.

 

[DanBa]

  Is there a usb otg cable that I could use that I don't need the adapter cable first?  I prefer it to end in usb b since that is what my dac/amp allow right now.

 
http://www.head-fi.org/t/595071/android-phones-and-usb-dacs/6285#post_11306308
A list of USB OTG cables:
http://goo.gl/4JyOe5

 

[kostaszag]

  Is there a usb otg cable that I could use that I don't need the adapter cable first?  I prefer it to end in usb b since that is what my dac/amp allow right now.

Yes
 
http://www.ebay.com/itm/221472355656?_trksid=p2060778.m1438.l2649&ssPageName=STRK%3AMEBIDX%3AIT

 

[DanBa]

  Thank you for the excellent post, however there are some things that are not quite right and might be causing you a little misunderstanding? The main ones are.
 
"it's arguably impossible to have bit perfect playback in a real-time system"
 
I must be misunderstanding you?  Computers all have bit perfect playback in real time.  Any errors in the bits have to be corrected in real time, or .zip files would always be corrupted, the numbers on bank accounts would be way off and so on.

 
I think you don't read the earlier sentence of the author:
"Let's all start by agreeing that audio is a real-time process."
http://www.head-fi.org/t/595071/android-phones-and-usb-dacs/6300#post_11315041
 
Real-time audio, like current USB audio, requires timely delivery of information, and can tolerate some loss to achieve this goal.
Music is seamless and continuous flow of information; it cannot afford retransmission of information in case of error in real-time music listening.
For example, the Real-time Transport Protocol (RTP) for real-time audio/video streaming runs on top of UDP.
https://www.ietf.org/rfc/rfc3550.txt
https://www.ietf.org/rfc/rfc768.txt
RTP and UDP don't have any retransmission procedure.
 
Non real-time audio, like transferring music file from one part of the world to the other, uses file transfer protocol like FTP. And FTP runs on top of TCP.
https://www.ietf.org/rfc/rfc959.txt
https://www.ietf.org/rfc/rfc793.txt
TCP has error detection and correction procedures with requests of retransmission of erroneous transmitted data. TCP is used by a lot of networking applications. Moreover, on the upper level, FTP has error recovery and restart procedures in case of some system failure.
 
 

   
"Because audio is real time, there is no error correction that can be done to this square wave, any resulting wave form IS your music."
 
This is not quite right, look up hysteresis loops as commonly used on input gates on digital logic, they "condition" the output levels and rise/fall times.  Used with the clock pulses, the width of the output pulses are synced with the clock pulses to produce output pules that are of the correct width and timing.
 

 
Interesting.
Do you have a link about hysteresis loops & input gates?
 
Even if the output pulses can be well shaped via some hysteresis loop gates; per your words "synced with the clock pulses", these output pulses could be modified in timing and in amplitude because the clock is affected by more and less EMI/RFI generated by the active computing device and there are fluctuations in the source reference voltage due to the variations of the computing device load.
 
 

 
"Jitter is an alteration of the duty cycle"
 
No, it is an alteration of the timing.  The pulse can be the same width, but delayed for example  - The rising edge and the falling edge being delayed by the same amount.  The pulse is still within normal parameters, just delayed.
 

 
Timing is duty cycle according to the jargon of the author:
"The timing, or duty cycle,"
http://www.head-fi.org/t/595071/android-phones-and-usb-dacs/6300#post_11315041
 

 
For example - In the example you give of jitter causing problems, he sorted it out, even though it was a delay of just 358ps, which translates to a frequency of a little over 2.793GHz for a delay of a whole pulse.  
 

 
The mentioned quotation is just to illustrate that the clock can be affected.
 
a noise + a noise + a noise + ... = a big noise
 
 

  Which is why jitter is important in computer circuits, but massively less of a problem with circuits working for audio.  Even the fastest digital circuitry associated with the actual audio signal is working at < 100MHz for even the highest quality (say a sampling rate of 384000Hz x 24 bits x 2 for Nyquist = 18.432Mhz BUT good rise times typically require at least the fifth harmonic, so = 92.16Mhz bandwidth requirement).  Jitter might be important there you might consider, but it is not, because it is already allowed for in the Nyquist frequency choice and the fifth harmonic.  Jitter on a pulse could affect the rise time, but it gets corrected by the circuits.  You can feed a sine wave into a hysteresis loop and get a square wave out, that is how good they are. I have tried to keep this as simple as possible, but where stubborn problems remain, more sophisticated circuits are used to correct jitter, like PLLs, and are another safeguard.  Any digital system has all the time-sensitive parts of it running from a single clock to reduce jitter further - Think of genlock in professional video gear to keep all cameras and processing equipment locked to exactly the same frequency and instant.
 
There are quite a few others, but you should be able to sort them out when you sort out the ones I've mentioned.
 

 
We should keep focus on the computing device side, the subject of the mentioned post; and not on the USB DAC side, because garbage in (USB DAC), garbage out (remember, there is no retransmission in current USB audio). On a side note, USB DAC makers keep saying that jitter is corrected by their latest circuits!
http://www.msbtech.com/products/analogDac.php?Page=../index
 
It is very easy to get the following experiment:
On a same audio system (same music file, same Android device, same USB DAC, same amp, same headphones, same cables, same ears), different music player software with inactive DSP (stock music player, Neutron, USB Audio Player PRO, ...) provides different sound quality.
http://www.head-fi.org/t/638387/best-android-music-player-app/240#post_10120655
 
In other words, the output PCM audio streams are not the same, or/and the EMI-RFI generated by the active Android device and propagated to the DAC are not at the same level.
 
It should be interesting that you, having a digital oscilloscope, compare these different output PCM audio streams.
 
Could it at least confirm or infirm the following diagram from a US college of engineering?
 

 

[StanD]

That amount of noise is much more that you will ever find in practical use.

 

[Theogenes]

 

Spoiler: Warning: Spoiler!

 

 
Thank you for the tip!
 
"Information search" added!
http://www.head-fi.org/t/595071/android-phones-and-usb-dacs/6285#post_11306308

 
No problem! 

 

[DanBa]

DSD capable Celsus Sound Companion One USB DAC/amp:
http://www.post76.com/wordpress/?p=73560
 
Sony Xperia Z3 >> USB OTG cable >> CS Companion One >> IEM
 

 

 

 

 

 

[DanBa]

Cmoar headset with USB out:
http://www.head-fi.org/t/595071/android-phones-and-usb-dacs/6255#post_11286714
https://www.kickstarter.com/projects/706938033/cmoar-virtual-reality-headset-with-integrated-elec
 
movie file > movie player running on a smartphone slotted into a Cmoar headset > PCM audio stream > Cmoar headset's USB out >> USB DAC/amp >> headphones
 

 

 

 

 

 

 
 

 

[aeneas1]

is anyone aware of a list that shows tablets that are confirmed usb/otg/dac friendly, that can stream digital music (files and/or services) without the need of special music players (usb audio player pro, etc.)?

 

[Tuco1965]

  is anyone aware of a list that shows tablets that are confirmed usb/otg/dac friendly, that can stream digital music (files and/or services) without the need of special music players (usb audio player pro, etc.)?

 
That would be complicated.  Too many variables.

 

[aeneas1]

   
That would be complicated.  Too many variables.

not sure i follow? compiling a list of tablets that have been confirmed to be usb/otg/dac compatible would be too complicated? actually what i was hoping for was a list that existed where tablet (and phone) owners posted whether or not their devices worked with audio out via usb/otg.

 

[Tuco1965]

Different versions of operating systems and different dacs affect what works.  It's not so cut and dried as you may think.  Just look at this thread.