[High_Q]

Expand on that or examples?  What is the cause of the interface issues?
 
Quote:

>The thing is: Asynchronous USB data transfer doesn't guarantee perfect sound. Well, technically speaking, it does. But bit-perfect transfer doesn't guarantee enjoyable sound.

async usb doesn't guarantee bit perfect transfer. That's BS. If you do interface issues from the cable or the usb chip or something, these will show up as dropped samples.

Since async transfer mode doesn't have retransmission on error, it can't guarantee bit-perfect transfer...It can however minimize timing errors in the form of jittteeer (bulk mode is still better, since the info at the DAC end comes out bit perfect/what left at the PC end

)


Otherwise, I don't find their comment particularly criminal, heh, I think the website means it in the "don't necessarily trust bs marketing and test it for yourself" way, which is not a bad way 'as long as you're happy'. On a bright stax system, I was more happy with a NOS dac sound than I was with Benchmark DAC1, so their comment makes sense to me (although that's not async usb, but you get the point)... That said, a decent DAC instead of the NOS one would have done better so maybe there is a point to cut the romantic BS where it grows since NOS dac marketing is full of fluffy bs as well

 

 

 

[svyr]

Expand on that or examples?
 


 

that was meant to say 'do have interface issues'. Other examples are well elaborated on in the usb spec for bulk mode and isochronous transfer (incl async, sync and adaptive modes).

>That said, a decent DAC instead of the NOS one would have done better so maybe there is a point to cut the romantic BS where it grows since NOS dac marketing is full of fluffy bs as well


That was just referring to DAC1 sounding serrating, and NOS dac having a rather high noise floor/NFB-10WM being more detailed, but not sounding harsh. (although I did have my own issues with NFB-10WM too ). A lot more of the difference seems down to preference/analog out stage.

 

[High_Q]

Ok, if you do have inteface issues.  Can you state the probability, and the causes?
 
Quote:

Quote:

Expand on that or examples?
 


 

that was meant to say 'do have interface issues'. Other examples are well elaborated on in the usb spec for bulk mode and isochronous transfer (incl async, sync and adaptive modes).

>That said, a decent DAC instead of the NOS one would have done better so maybe there is a point to cut the romantic BS where it grows since NOS dac marketing is full of fluffy bs as well


That was just referring to DAC1 sounding serrating, and NOS dac having a rather high noise floor/NFB-10WM being more detailed, but not sounding harsh. (although I did have my own issues with NFB-10WM too

)

 

 

[svyr]

Ok, if you do have inteface issues.  Can you state the probability, and the causes?
 


 

for async, it could be anything that will cause the samples past usb chip on the DAC to not be the same as the input file's
Causes and probability - no idea, I don't particularly believe in magical USB cables, so I guess it'd have to be async issues (clock problems maybe, usb controller problems, or protocol issues itself, since it sounds like async adjusts the flow of data in a feedback loop of some sort basically letting the PC know whether to slow down or speed up the data flow rate. I guess if (the mot wasn't simplifying and) the clock is fast enough, you shouldn't lose any samples)
The later is speculation and is based on http://www.head-fi.org/forum/thread/258551/how-does-usb-audio-transfer-work#post_3273142 . You can check with the MoT how it actually works . All I can tell is bulk mode transfer is by design removed from these issues as it just does vanilla data transfer the way your usb HDD will with error checking and re-transmission on error (see the post a few pages back)

 

[vandaven]

Quote:

 
http://www.hifi-advice.com/USB-synchronous-asynchronous-info.html

Of course it's buffered, but not inside the audio interface:
 
http://www.mhsecure.com/technotes/v5MixerOverview/CoreAudio.html
 

 

[uelover]

Quote:

Of course it's buffered, but not inside the audio interface:
 
http://www.mhsecure.com/technotes/v5MixerOverview/CoreAudio.html
 

 
Quote:

Come on, you are saying it is streaming and it is doing error correction?  I know error correction does take place with digital data once data is demodulate.  Also, when you say stream, you can say video is being steamed, but it is fetched and loaded to memory before the decoding process begins.  Audio works the same way, on my ipod there is a brief pause before play because of the hard drive lag, dated is transferred during the lag.

Yes. It is buffered on the PC/Mac side but not on the DAC side.
 
The link you quoted touches on audio input from external audio devices to a mac. The mac is on the recipient end and thus buffering could occur.
 
 
I am answering High_Q's statement as he likened USB audio streaming to online video streaming.

 

[vandaven]

It's an I/O buffer. Thus on both sides. A buffer for the input and a buffer for the output. Of course not inside the device. I referred to buffers way earlier in this thread. For example, a buffer underrun would be the result of a too small buffer size in relation to cpu / bus clock deviation. If you only listen to the music (without recording it, like I do), you normally never worry about the buffer latency. In case you need proof, I could post you some evidence. It's easily measurable, as Pro Tools (with an Avid interface) has I/O buffer compensation. Thus, a re-recorded impulse will only show the latency induced by the converter and the core audio system on any 3rd party device.
 

 

[00940]

 
You're still at it after 36 pages ? And not a single one of you living in the English speaking world was able to locate the January issue Hi-Fi news (in which Paul Miller apparently demonstrates through measurements that different usb cables cause different levels of jitter in the DAC they feed) ?
 
You really don't value your time... you could be debating what level of jitter is audible, imagine how much funnier it would be 

 
 
PS: there are buffers in modern SPDIF receivers. 

   Those are actually working in a very similar way to the buffers in the most common USB receivers (but not in the same way as the buffers inside asynchronous usb receivers... ooh the joy of multiple protocols on the same interface); that allowed TI to share the SPACT technology in between their spdif receivers (dir1703) and usb receivers (early pcm270*). The buffers inside the computer are pretty much irrelevant to a discussion about usb cables on the other hand.

 

[vandaven]

That is indeed very interesting. Is there any possibility to view that article, as I did measurements with different usb cables on multiple usb audio interfaces that did not show any noticeable difference between the cables.
 

 

[00940]

I wish... Someone sent me the article of December 2010, in which Paul Miller shows the effects of various aspects of the source computer on the jitter of an usb dac but I couldn't locate till now the January 2011 article. All I've got are second hand accounts on the web.
 
It's possible to suscribe to their digital edition for 19£, for a year + access to the archives, but apparently not to buy a single digital issue.

 

[tkteo]

Uh, if someone scanned it and posted the relevant page on here, it would be against copyright, right? (no pun intended)

 

[uelover]

duplicate posts.

 

[uelover]

 
@vandaven: I understand very well the buffering that takes place for audio in/out on computers. I am merely pointing out that the bulk of the link you quoted explains on Coreaudio's role in audio inputs. I am in nowhere saying that buffering does not take place for audio output. Please don't read things with a colored lens.
 
 
This is a misstatement suggesting that a similar process is taking place on the DAC that I feel the need to correct - there is nothing being fetched and loaded into 'any' memory on a DAC before decoding starts and for USB audio, data is continuously flowing from the computer to the DAC:
 
Quote:

The cable is just a transfer medium, the decoding and its timing are done on the DAC itself, and it should be very accurate.  The data does not flow through the cable during play.  I think people are confusing it with an analog signal interconnect.  That's probably how people get bought into the scam. For example, just look at how video is streamed through network.  The data is fetched before it is decoded.

 
Quote:

Come on, you are saying it is streaming and it is doing error correction?  I know error correction does take place with digital data once data is demodulate.  Also, when you say stream, you can say video is being steamed, but it is fetched and loaded to memory before the decoding process begins.  Audio works the same way, on my ipod there is a brief pause before play because of the hard drive lag, dated is transferred during the lag.

 

 

[High_Q]

That's is true, data does not get prefetched to the DAC. Apologies if it has caused any confusion, I've realize what I have written after uelover pointed it out.  I typed it out right after I woke up, my brain was a little fuzzy.

  For some reason, I have mixed up data transfer and streaming though network, where data gets transferred first, then gets loaded, then decoded for the output device.  But, yes, data get's loaded to memory and it is decoded from the external DAC.  Data must be transferred through usb from the pc to be decoded by the external DAC.    

 

[DaBomb77766]

I'm pretty sure it's a given that different cables can have different levels of jitter.  After all, isn't the USB spec designed to reduce jitter as much as possible?  The real question is whether or not the miniscule differences in jitter from one cable to another is audible or even measurable in the audio signal.