[Yoga Flame]

Indeed the Apogee Duet will only work on Macs. It runs on Firewire too.
 
Gatepc, if you need some nice looking flat cable copper interconnects, I've got some for sale used. See my sig. They are quite sturdy and the flat profile lets you run them between or underneath spaces that would be a tight fit otherwise. I shall refrain from making claims about their sonic signature though. Lol.

 

[Gatepc]

thank you for the offer though I have found a pair on monoprice that appear to be just fine for what I will need and they only cost 5 dollars  
Quote:

Indeed the Apogee Duet will only work on Macs. It runs on Firewire too.
 
Gatepc, if you need some nice looking flat cable copper interconnects, I've got some for sale used. See my sig. They are quite sturdy and the flat profile lets you run them between or underneath spaces that would be a tight fit otherwise. I shall refrain from making claims about their sonic signature though. Lol.

 

[doctorcilantro]

Quote:

Asynchronous does not make anything "sound better", though it does allow for accuracy in the digital signal.

?
 

 

[Yoga Flame]

I guess that means if your digital audio is already working properly, then asynchronous will not make it sound better. But if there is some timing problem in the setup, then making it asynchronous will fix that through its greater accuracy.

 

[FallenAngel]

Nope, it's "working properly" as in transmitting a data stream multiplexed with timing information.  Async transmissions allows for error checking, correction and depending on implementation (hopefully it's good), should allow for "perfect" transmission of both timing and data information.
 
As for whether the classical streaming protocol actually failing, that is very questionable and as long as data is sent within a certain spec, no amount of jitter will stop the data steam from being corrupt (or if it does, you'll know when signal unlocks).

 

[Yoga Flame]

Ah ok, good to know. So the only advantage of async is that it is less likely for the signal to unlock? In other words, if you don't have a problem with signal unlocking, then all else being equal there's little point in async?

 

[FallenAngel]

I wouldn't go as far and claiming async = no possible errors, but I'm not jumping on that bandwagon just yet.

 

[digger945]

Check me on this, but I'm pretty sure that there is no error correction used in USB audio, async or adaptive. It's a stream and that's it. When you press play it comes out and what you get is what you get. I'm still learning, so go easy on me, but I think that the only difference between the two is that using adaptive USB audio the computer sends the audio data packets at it's own time slot, and the USB audio receiver(PCM2707 for example) must then adapt it's timing to properly buffer and resend the data in the appropriate format.
 
With async, the device plugged into the USB port will now have control over the timing of the data sent by the computer, so no reclocking is necessary. This is accomplished two ways, software drivers installed to somehow control the usb and allow the audio data to be sent at the devices timing, and firmware that's installed on the device that somehow accomplishes the timing externally without the need for software installed on the machine.
 
The part I don't understand yet is the USB slot frequency and packet size. Still learning about Tokens and Handshakes.

 

[FallenAngel]

No reason to keep the stream "dumb", can just send more data than necessary, starting from "current" and keep sending a little more in advance - simple buffering, device simply starts playing after a VERY short pause.  That keeps the protocol "almost streamed", and allows for error correction and requirement on source timing is thrown out altogether.  Well, that's how I would write the firmware, haven't read the code for commercial implementations yet.  To say it took WAY too long to even get to this point is the understatement of the digital audio "century".