USB cable quality - Page 12 - 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, 08:37 PM   #111
phofman is offline phofman  Czech Republic
diyAudio Member
 
Join Date: Apr 2005
Location: Pilsen
Quote:
Originally Posted by qusp View Post
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
That may be possible since I honestly have no idea which clock you are talking about. Your solution is USB async audio with no feedback and much longer buffer to compensate for the missing incoming bitrate control.
  Reply With Quote
Old 27th March 2013, 08:42 PM   #112
qusp is offline qusp  Australia
diyAudio Member
 
qusp's Avatar
 
Join Date: Oct 2009
Location: Brisbane, Australia
Quote:
Originally Posted by phofman View Post
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.




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.
its not my solution, iancanada here created it, I was just part of prototype testing and made some suggestions. clearly you arent aware of the project/product. heres the fifo wiki that hochopeper put together, has all important links.

it was developed as a purely audio solution and was dac and source agnostic, to basically enable bitperfect extremely low jitter i2s and master clock to your dac of choice. most are using it with ESS, but it doesnt have to be. it produces the same quality output no matter what you plug into it (within reason).

I never said USB couldnt improve to the same level, but its pretty much impossible to better it, its limited only by the quality of the clock used. but to match it you need most of the same parts. you need galvanic isolation or otherwise isolated from USB ground, this will throw the possibility of matching it out the window. you need local memory/fifo, you need clock, you need flip flops, you need an impedance controlled, preferably buffered connection to the dac and you need a very low noise clock power supply. but you would still be stuck with USB only, not spdif.

it doesnt have a USB input, it has i2s input and i2s + MCLK output and there is a matching spdif module.

I think we are actually mostly on the same page, except you havent seen the project i'm talking about before. its pretty physically large with all the options, which is a pain. but the pricing is pretty much a gift, dacs with this sort of tech cost pretty serious dollars.

check out the wiki and the linked manuals for an overview

Last edited by qusp; 27th March 2013 at 08:49 PM.
  Reply With Quote
Old 27th March 2013, 08:55 PM   #113
diyAudio Member
 
Join Date: Jun 2011
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.
Quote:
Originally Posted by phofman View Post
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.
I fail to see what useful distinction you are seeking to draw here. '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.' How is this distinct from 'bursty' and how is it 'isochronous'?

Quote:
Originally Posted by Bunpei View Post
May I ask a few questions? Please feel free to ignore any of them.

1. "Asynchronous USB 2.0 input module"
Does this mean "USB Audio Class 2.0" compatible or simply "USB 2.0 (High-speed)" compatible?
If it is "USB Audio Class 2.0" compatible, it does require a driver software in Windows environment and does not in Mac OS environment. Is it correct?
Quote:
Originally Posted by Russ White View Post
Thanks! I am happy to answer.

1) USB Audio Class 2
Now, perhaps I am misled, but here we have an "Asynchronous USB 2.0 input module" described as operating under 'USB Audio Class 2' by its developer.

What useful contribution are you seeking to make to the conversation?
  Reply With Quote
Old 27th March 2013, 09:00 PM   #114
phofman is offline phofman  Czech Republic
diyAudio Member
 
Join Date: Apr 2005
Location: Pilsen
I see, it is an asynchronous FIFO. Hats off to everyone involved, certainly useful device. But it is not really related to USB.

USB async works basically the same way as if this FIFO was fed by standard adaptive USB, but is less complicated (only one buffer involved, no PLL in the adaptive USB part) and enjoys the luxury of having a rather fast control feedback, allowing it to keep the buffer size much shorter. As a bonus it offers standardized support for switching sample rates, sample sizes, support for various controls (volume, switching), and lots of other options. All that supported by one standard driver. In reality some devices deviate from the standard and specific quirks have to be coded into the driver.
  Reply With Quote
Old 27th March 2013, 09:04 PM   #115
qusp is offline qusp  Australia
diyAudio Member
 
qusp's Avatar
 
Join Date: Oct 2009
Location: Brisbane, Australia
I didnt relate it to USB... you made that connection and i've been fighting with that confusoin ever since due to the confusingly similar architecture I imagine

I mentioned it only because of the excellent end result and because it uses similar techniques as USB and is completely impervious to the effects of different USB cables...

there is no PLL, its strictly what goes in comes out as far as samplerate. is separated from its clock domain if it had one and clocked out of memory using a fresh, local very high quality clock of the same clock multiple 22.1x or 24x (44.1->384kHz). its only async wrt the input, not async wrt the samplerate. it reclocks, doesnt resample


@ CC regarding the TP device

its i2s output is asynchronous wrt the input and its USB2, while also being UAC2 compliant.

Last edited by qusp; 27th March 2013 at 09:17 PM.
  Reply With Quote
Old 27th March 2013, 09:13 PM   #116
phofman is offline phofman  Czech Republic
diyAudio Member
 
Join Date: Apr 2005
Location: Pilsen
Quote:
Originally Posted by counter culture View Post
I fail to see what useful distinction you are seeking to draw here. '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.' How is this distinct from 'bursty' and how is it 'isochronous'?
I am trying to avoid a confusion. UAC1 and UAC2 are a different categorization to adaptive and asynchronous. There can be adaptive UAC2 devices (not async) and there are UAC1 async devices. Just clearing up the terminology

Bursty and isochronous are basically opposites. In burst mode (bulk) the device is trying to transport as much data as possible in one frame. In isochronous mode the amount transported in each frame is kept constant at best, each frame transferring only amount corresponding to the frame time length. The async feedback causes the amount fluctuate only by little. Actually the linux alsa driver uses notions like "current rate" and reports values such as 44.050 Hz.

Last edited by phofman; 27th March 2013 at 09:15 PM. Reason: fix
  Reply With Quote
Old 27th March 2013, 09:16 PM   #117
phofman is offline phofman  Czech Republic
diyAudio Member
 
Join Date: Apr 2005
Location: Pilsen
qusp, I think we are set now Certainly an interesting project, especially since it supports data coming from various sources.
  Reply With Quote
Old 27th March 2013, 09:23 PM   #118
qusp is offline qusp  Australia
diyAudio Member
 
qusp's Avatar
 
Join Date: Oct 2009
Location: Brisbane, Australia
hehe no dramas, yes Ian is a machine too, so damn productive given hes holding down a medical instrumentation PCB design job synchronously

OK back to USB cable gremlins

Last edited by qusp; 27th March 2013 at 09:26 PM.
  Reply With Quote
Old 27th March 2013, 09:38 PM   #119
diyAudio Member
 
Join Date: Jun 2011
OK, I think we're all pretty much on the same page now, sorry for any friction.

Given that it were indeed the case that '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' under some regime regardless of how described, then the size of the buffer and the latency could be arbitrarily reduced with a consequent saving in complexity and cost.

This is how the damn thing should have been organised in the first place and if such an arrangement is not supported under UAC2 then all I can say is 'Why the hell not?'

Were it not (as you correctly surmised, qusp) that I believe any difference to be inaudible, or at least of no consequence, I would write the driver and build the device myself.
  Reply With Quote
Old 27th March 2013, 10:46 PM   #120
phofman is offline phofman  Czech Republic
diyAudio Member
 
Join Date: Apr 2005
Location: Pilsen
Quote:
Originally Posted by counter culture View Post
This is how the damn thing should have been organised in the first place and if such an arrangement is not supported under UAC2 then all I can say is 'Why the hell not?'
The async mode is supported in UAC1 as well as UAC2.

The adaptive mode is supported in UAC1 as well as UAC2.

IOW:

UAC1 supports adaptive as well as async mode.

UAC2 supports adaptive as well as async mode.

Because UAC2 is a refined advancement of UAC1.

I agree the async mode should have been used from the very beginning. But we should realize most manufacturers use ready-made chips. And there was none implementing async mode until the relatively recent XMOS for UAC2. And manufacturers in general do not want to complicate their life too much which coding their own async mode support would certainly bring.

And there is always the question of actual audible difference
  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 11:19 PM.


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