1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.

    Dismiss Notice

Android phones and USB DACs

Discussion in 'Portable Source Gear' started by nztechfreak, Feb 9, 2012.
First
 
Back
413 414 415 416 417 418 419 420 421 422
424 425 426 427 428 429 430 431 432 433
Next
 
Last
  1. NZtechfreak
    I use the "site:" search in Google a lot. Nice tip for those unaware!
     
  2. 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.
     
  3. 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.
     
    VanceC and Thad-E-Ginathom like this.
  4. 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.
     
  5. DanBa
     
    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

     
  6. kostaszag

    Yes
     
    http://www.ebay.com/itm/221472355656?_trksid=p2060778.m1438.l2649&ssPageName=STRK%3AMEBIDX%3AIT
     
  7. DanBa
     
    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.
     
     
     
    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.
     
     
     
    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
     
     
    The mentioned quotation is just to illustrate that the clock can be affected.
     
    a noise + a noise + a noise + ... = a big noise
     
     
     
    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?
     
    0000000.jpg
     
    MikeyFresh likes this.
  8. StanD
    That amount of noise is much more that you will ever find in practical use.
     
    DJScope likes this.
  9. Theogenes
     
    No problem! 
     
  10. 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
     
    IMG_7724.jpg
     
    IMG_7594.jpg
     
    IMG_7697.jpg
     
    IMG_7703.jpg
     
    IMG_7669.jpg
     
  11. 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
     
    Slide1.jpg
     
    Slide2.jpg
     
    Slide3.jpg
     
    Slide4.jpg
     
    Slide5.jpg
     
    Slide6.jpg
     
     
     
  12. 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.)?
     
  13. Tuco1965
     
    That would be complicated.  Too many variables.
     
  14. aeneas1

    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.
     
  15. 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.  
     
First
 
Back
413 414 415 416 417 418 419 420 421 422
424 425 426 427 428 429 430 431 432 433
Next
 
Last

Share This Page