USB cable quality - Page 11 - diyAudio
Go Back   Home > Forums > Source & Line > PC Based

PC Based Computer music servers, crossovers, and equalization

Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools Search this Thread
Old 27th March 2013, 06:45 PM   #101
diyAudio Member
 
Join Date: Jun 2011
OK, I will go and have another look but I understood that UAC1 asynchronous was available using bulk mode, but this requires a custom driver and there is no guaranteed bandwidth, and that UAC2 will support true bursty download controlled from the DAC end under the standard. If it doesn't then it damn well ought to, because that is the nub of the problem we are discussing.

Last edited by counter culture; 27th March 2013 at 07:04 PM.
  Reply With Quote
Old 27th March 2013, 07:19 PM   #102
diyAudio Member
 
Join Date: Jun 2011
OK. Looking at this:- The Asynchronous USB Audio class 2 module. ...it operates natively under MacOS UAC2 driver.
  Reply With Quote
Old 27th March 2013, 07:36 PM   #103
qusp is offline qusp  Australia
diyAudio Member
 
qusp's Avatar
 
Join Date: Oct 2009
Location: Brisbane, Australia
Quote:
Originally Posted by counter culture View Post
Given access to suitable test equipment I could design a device meeting or exceeding the jitter performance you quoted, and under UAC2, considerably less complicated, less expensive and with lower latency.

You will see such devices appear in the future, when you do, you can come back and I will explain them to you.
I doubt that very much...

the jitter I mention is actual period jitter measurement of the sum total of the clock buffer and clock (just the 2 parts jitter in series); at the output of the buffer, thats all the jitter there is, still you dont understand the mechanism after several iterations of the function blocks, so its a bit laughable that you think you can do better.

but if you are developing a commercial product.... then I shouldnt explain further someone elses IP that isnt mine to give away.

predicted jitter will not be accepted, i'll be very interested to see you even produce a meaningful measurement below 1ps...

Last edited by qusp; 27th March 2013 at 07:54 PM.
  Reply With Quote
Old 27th March 2013, 07:39 PM   #104
phofman is online now phofman  Czech Republic
diyAudio Member
 
Join Date: Apr 2005
Location: Pilsen
Quote:
Originally Posted by qusp View Post
yet you are stuck with USB and USB only... and without having a chunk of local memory and an isolated clock domain, you will have higher jitter.
?? Do you really understand the way usb asynchronous audio works? There is a local buffer and there is isolated clock domain, just like in your solution. The major and key difference is the device sends feedback messages to the host telling it to speed up/slow down the data transmission rate to keep the buffer optimally filled.

As a result the local buffer can be kept short, allowing for low latency operation.


Quote:
i'm not aware of any USB audio interfaces that adjust video delay, they just have a smaller buffer so that the delay is very small.
In one of my previous posts I talked about bDelay UAC parameter which reports the delay incurred within the device itself.

Parameters like that (together with usually much larger delays caused by DMA buffers) can be reported upstream - see function snd_pcm_delay ALSA project - the C library reference: PCM Interface of linux alsa API. And it gets used in video applications for delaying the video

mplayer2 - master mplayer2 repository

mplayer2 - master mplayer2 repository

The reality is most USB interfaces report either 0 or 1 frame (followed from google search of lsusb outputs). Which may be correct or incorrect. And as a result the snd_usb_delay method does not add the value into the total delay calculation https://git.kernel.org/cgit/linux/ke.../usb/pcm.c#n42 . I will ask about it on the alsa-devel mailing list.

Last edited by phofman; 27th March 2013 at 07:58 PM.
  Reply With Quote
Old 27th March 2013, 07:44 PM   #105
diyAudio Member
 
Join Date: Feb 2009
Location: UK
Going back to the topic, however, is it not the case that in the isochronous mode, the cable will have some effect on the timing, no matter how slight? Maybe it only results in 1 ppm clock change every hour, but it's hard to guarantee it absolutely, and that's all that's needed for some people to justify spending hundreds on the cable.
  Reply With Quote
Old 27th March 2013, 08:07 PM   #106
GoatGuy is offline GoatGuy  United States
diyAudio Member
 
Join Date: Dec 2012
Location: SF Bay Area
If 1 PPM is enough for people to justify spending hundreds on some tinned copper, insulation and post-manufacturing spruced up connectors (gold plating, of course!) ... then the only thing to remind one's self is, "a fool and his money are soon parted". How many wonderful systems have I seen, with little pointy cones raising speakers off the ground to supposedly squash doppler shifts, and with little pyramidal foam supports to lower the capacitance of their $100/foot speaker cables, their wicked-cool monoblocks and all separate stuff, including totally re-capacitored high end pre's. ... and their music collection is just pathetically thin. One guy I know had spent most of his adult life ever tuning things, being a real DIYer, but had fewer than 50 great recordings. Had he spent 50% on the system, it still would have been utterly awesome. The other 50% could have gone into buying thousands of great performances to actually use the system to play back.

GAS. Gear Acquisition Syndrome. At some point a lot of us slump into it, and get a kick out of it. I've bought cameras for years ... that I've barely used, and hit myself over the head for ever buying ... yet, I look at photography magazines, and the GAS lust comes back. Same for audio. Same for computers. And sadly, I think GAS lies at the very core of the current fantasy/mania that has gripped so many "kids" with their iPhones and iDevices.

Like my brother-in-law... who has literally camped out overnight to get each successive new iPhone and iPad and iBook. Yet, analogous to the above, he hardly uses the devices for any but their most banal purposes. His sound system is top shelf, and his recordings are all on the bottom shelf. His camera almost has no peers, yet his shots are with remarkably few exceptions, banal, trite, badly framed and overwrought.

GAS

All the rest of the foregoing re: USB cables, isochronous, asynchronous, and so on ... is just abstruse. Bottom line is - there is no difference for nominally made, "working to the optimum spec" cables. Good cable, good wire, good connectors ... not fancy, but just "made right" by large manufacturers ... delivers the bits. There is NO "jitter" that the wire somehow gives that is improved upon by having reconstituted Unicorn horn insulation, unobtainium wire, or blessed-on-the-thighs-of-virgins connector-ends.

GoatGuy
  Reply With Quote
Old 27th March 2013, 08:09 PM   #107
qusp is offline qusp  Australia
diyAudio Member
 
qusp's Avatar
 
Join Date: Oct 2009
Location: Brisbane, Australia
argh, we are not talking about the memory for buffered USB packets here, we are talking about buffered i2s/PCM directly at the dac clock and that buffer is asynchronous wrt to the input, but clocking the dac synchronously and clocking that data out of local fifo memory using that same dac master clock to clock the flip flops after galvanic isolation.

the USB clock that controls the async bursts is a different matter and often an order of magnitude less accurate. the buffer can be kept small yes with USB due to feedback, but the same elements i'm talking about are needed to have i2s and MCLK that is the sum total of the MCK at the buffer/flip flop that drives the dac. all of the available USB interfaces and interface chips on the market, aside from custom solutions that include a memory block and flip flops as well, are higher jitter. XMOS, CMEDIA etc are all significantly higher jitter without further cleaning up.

I suggest you read my post again keeping in mind i'm talking about sample accurate video/audio sync. read the part where I say the same elements can be arranged in a couple other ways for the same result, but the same basic elements are needed.

the reason for the large local buffer is because it was designed to work with all manner of sources USB, Spdif etc.

but look, I suggest you check it out, i'm not selling it, I have no need to explain this all again or argue it.

Quote:
Originally Posted by phofman View Post
?? Do you really understand the way usb asynchronous audio works? There is a local buffer and there is isolated clock domain, just like in your solution. The major and key difference is the device sends feedback messages to the host telling it to speed up/slow down the data transmission rate to keep the buffer optimally filled.

As a result the local buffer can be kept short, allowing for low latency operation.




In one of my previous posts I talked about bDelay UAC parameter which reports the delay incurred within the device itself.

Parameters like that (together with much usually larger delays caused by DMA buffers can be reported upstream - see function snd_pcm_delay ALSA project - the C library reference: PCM Interface of linux alsa API. And it gets used in video applications for delaying the video

mplayer2 - master mplayer2 repository

mplayer2 - master mplayer2 repository

The reality is most USB interfaces report either 0 or 1 frame (followed from google search of lsusb outputs). Which may be correct or incorrect. And as a result the snd_usb_delay method does not add the value into the total delay calculation https://git.kernel.org/cgit/linux/ke.../usb/pcm.c#n42 . I will ask about it on the alsa-devel mailing list.

Last edited by qusp; 27th March 2013 at 08:23 PM.
  Reply With Quote
Old 27th March 2013, 08:15 PM   #108
phofman is online now phofman  Czech Republic
diyAudio Member
 
Join Date: Apr 2005
Location: Pilsen
Quote:
Originally Posted by counter culture View Post
OK, I will go and have another look but I understood that UAC1 asynchronous was available using bulk mode, but this requires a custom driver and there is no guaranteed bandwidth
The protocol you are talking is not USB audio class v.1 standard which has always been isochronous. I already posted a link to UAC1 async devices on the market (some unavailable anymore). A well known example of UAC1 async (with minor deviation from the standard) is EMU 0202/0404 USB soundcard.

You are talking about proprietary protocols developed by some DAC producers, a typicall example being M2Tech HiFace1 and its "clones".


Quote:
Originally Posted by counter culture View Post
and that UAC2 will support true bursty download controlled from the DAC end under the standard. If it doesn't then it damn well ought to, because that is the nub of the problem we are discussing.
UAC1/2 runs isochronous, i.e. continuous fluent delivery of data every frame to the device. Bursty download is typical for bulk mode transmission and has never been a part of the UAC standard.

Last edited by phofman; 27th March 2013 at 08:29 PM.
  Reply With Quote
Old 27th March 2013, 08:25 PM   #109
phofman is online now phofman  Czech Republic
diyAudio Member
 
Join Date: Apr 2005
Location: Pilsen
Quote:
Originally Posted by qusp View Post
argh, we are not talking about the memory for buffered USB packets here, we are talking about buffered i2s/PCM directly at the dac clock and that buffer is asynchronous wrt to the input, but clocking the dac synchronously and clocking that data out of local fifo memory using that dac master clock to clock the flip flops after galvanic isolation. the USB clock that controls the async bursts is a different matter and often an order of magnitude less accurate. the buffer can be kept small yes with USB due to feedback, but the same elements i'm talking about are needed to have i2s and MCLK that is the sum total of the MCK at the buffer/flip flop that drives the dac.
Sorry, I do not understand which clock you are talking about. The crystal-based clock in async usb receiver drives the I2S bus, I do not see any other.


Quote:
I suggest you read my post again keeping in mind i'm talking about sample accurate video/audio sync. read the part where I say the same elements can be arranged in a couple other ways for the same result, but the same basic elements are needed.
Sure there are always many ways. I gave you my reasons why I prefer the encapsulated feedback of async USB. You like your solution, fair enough. I just do not see any way your solution is technically superior to async USB. It is perfectly possible the ready-made existing implementations which all manufacturers use to avoid the USB stack details are not optimal and your specific implementation measures better. But there is no technical reason a USB async implementation could not improve to reach the same level.
  Reply With Quote
Old 27th March 2013, 08:26 PM   #110
qusp is offline qusp  Australia
diyAudio Member
 
qusp's Avatar
 
Join Date: Oct 2009
Location: Brisbane, Australia
sorry yes, my use of burst above is incorrect for this case too, but the rest stands, just remove that word, thought i'd post that here rather than another edit, which could be missed, as I think that may have happened with at least one of my previous posts as well, based on your reply
  Reply With Quote

Reply


Hide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How to isolate USB instrument from interference conducted by the USB cable sunkai Parts 3 25th April 2014 02:19 PM
USB Cable sergedc Digital Source 3 23rd April 2012 11:44 AM
Will wireless USB hub lower the quality of my USB sound card output? rg12 Digital Source 6 6th January 2011 08:47 PM
USB DAC (in the cable!?) rjm Digital Source 5 13th May 2004 08:19 AM


New To Site? Need Help?

All times are GMT. The time now is 07:30 AM.


vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2014 DragonByte Technologies Ltd.
Copyright 1999-2014 diyAudio

Content Relevant URLs by vBSEO 3.3.2