Asynchronous usb for Expert 250 Pro CI?

[RvdH]

Hi all,

As far as I am informed, asynchronous usb is better than ‘normal’ usb. Something with the clock I understood. Which makes it as good or better as ethernet when connecting e.g. a Nucleus.

Does anyone know if the Expert 250 Pro has the possibility to process asynchronous usb? And what the difference is between asynchronous and synchronous usb?

Thanks.

[Pim]

The invention of asynchronous USB has been credited to Gordon Rankin, quite a number of years ago now. John Darko did an interview with him you could google. That could explain a bit.

Ever since Gordon's invention, there haven't been many DACs built with 'normal' USB. Asynchronous is basically industry standard.

In a nutshell; USB sends data in packages so if you were to unpack those packages as they come in and just play them, there would be a timing mess up. Asynchronous USB takes the packages, unpacks them from memory using it's own clocking system and then plays it. Timing issue solved.

[ogs]

Yes, the Devialet amps has an asynchronous USB bus (used to be an XMOS chipset in the 'old' amps, probably also XMOS on the CI board). I'm not sure it is better than ethernet, maybe 'as good' is more correct. Depends on the implementation.

An asynchronous USB link lets the endpoint (in your case the Devialet) control clocking of data input while on a synchronous link the host (computer) pushes data using its own clocking.

@Pim you beat me there!

[thumb5]

I can try to shed some light on the difference between asynchronous and synchronous USB audio.  In simple terms, the difference between the two modes is about who is in charge of the audio sample clock: in synchronous USB the source's sample clock is the master, whereas in asynchronous USB the sink's clock is the master.

To explain this in more detail, we have to think about the different kinds of clock that might be present in a system  where a source (e.g. streamer) sends audio data over USB to a sink (e.g. a DAC, such as a Devialet amp).

First, the source will have a clock at which it naturally generates audio samples.  This will probably depend on the stream it's decoding or the format of the file it's playing.  For the sake of argument, let's assume it's 48 kHz.

The source has to somehow communicate to the sink that it wants to play a 48 kHz audio stream, and the sink will then know that it has to be using a 48 kHz sample clock as well.  The USB audio class defines a way to do this, but exactly how it does so isn't important for understanding the difference between synchronous and asynchronous USB audio.  At this point the sample size  or "bit depth" (for example: 16 bits, stereo) is also agreed.

Once the sample rate is agreed, the source will start sending samples to the sink over USB.  There is another clock involved here: the audio samples are not sent evenly at a rate of one every 20.8 microseconds (48 kHz), but in "bursts" (frames/micro-frames) defined by the operation of USB.  These bursts are every 125 microseconds (8 kHz) on high-speed USB, which means each burst contains 6 audio samples from the original 48 kHz stream.

In synchronous USB audio, the sink locks its audio sample clock to match the rate at which USB frames arrive; in our example it "multiplies up" the 8 kHz USB frame rate to generate the 48 kHz clock it needs to "play" the audio samples.  In this scheme, there could be quite a bit of jitter in the resulting audio sample clock because the USB frame clock is not especially clean.

In asynchronous USB audio, the sink generates its own audio sample clock which could be from a high-precision, low-jitter oscillator.  But then the question is: how do the source and sink guarantee that their independent audio sample clocks stay in step so that they run at exactly the same rate (overall)?  If they don't run at the same rate, then over a long period of time the source would be sending samples slightly faster or slower than the sink could play them, which means either samples would have to be dropped or "made up" to fill gaps.

What happens is that the sink monitors the rate at which audio samples are arriving in the USB frames, and over a period of time compares this rate to the rate it's playing them (that is, its own sample clock).  If there is a difference, it sends feedback to the source telling it to slow down or speed up a bit.  In this way the sample clock on the source ends up being "controlled" by the sink so that it matches the rate of the sink's sample clock.  The benefit of this approach is that the sink can have a very high-quality sample clock so that samples are played back with low jitter, independently of what happens upstream.

Going back to the Devialet: I haven't used USB as an input so I'm not absolutely sure, but I'd be very surprised if it's not using the asynchronous mechanism.

One final point: you might also hear the term "isochronous transfers" used when talking about USB audio.  This describes the mechanism by which audio samples are sent in bursts at a fixed rate (8 kHz for high-speed USB).  Isochronous transfers are used because the audio sample data is time-critical, and needs guaranteed bandwidth on the bus; the USB specification defines isochronous transfers as the way to reserve bandwidth.  Both asynchronous and synchronous USB audio is sent using isochronous transfers.

[Ecki]

I guess the principal problems here are very similar to any digital data transmission done in "real time" (vs. transmit the whole file(s) in advance).
Does anybody know the details of error handling in USB audio?
AFAIK there is no repetition of corrupted data packets, but there will be some kind of error detection/correction (redundancy of data via mathematical codes).

As i'm using a rather short, well shielded USB cable, there is no fear of excessive data corruption, but it would be very interesting to see the degree of "data correctness" finally achieved. But i don't know any home entertainment device offering that degree of access to internal processing.

[thumb5]

As you suggested, errors can be detected (by a CRC) but errored input frames are dropped and do not result in retransmissions. I guess it's up to the DAC to decide what to output in place of errored data (as far as I know, this is not defined by the USB audio class specification).

[Pim]

I guess the principal problems here are very similar to any digital data transmission done in "real time" (vs. transmit the whole file(s) in advance).
Does anybody know the details of error handling in USB audio?
AFAIK there is no repetition of corrupted data packets, but there will be some kind of error detection/correction (redundancy of data via mathematical codes).

As i'm using a rather short, well shielded USB cable, there is no fear of excessive data corruption, but it would be very interesting to see the degree of "data correctness" finally achieved. But i don't know any home entertainment device offering that degree of access to internal processing.

Since USB can handle a maximum speed of 480 Mbit/s and high quality music streaming lies around the 3 Mbit/s mark, there's very little chance any data will be lost.

[RvdH]

Many thanks to all that took the trouble to answer!

I put A NUC running ROCK in a fanless akasa case with its Teddy Pardo power supply right next to the 250 and connected through usb.with a very good cable.The improvement was impressive.
Now I don’t need an audio grade switch with its audio grade power supply and fancy ethernet cables anymore. Only downside: volume does not sync with Roon as it does over ethernet.

[Ecki]

Since USB can handle a maximum speed of 480 Mbit/s and high quality music streaming lies around the 3 Mbit/s mark, there's very little chance any data will be lost.

Principally, you are right, of course. My main point is, if there are data/connection related problems, i'd like to know that (e.g. via an app interface). In order to correct it (switching devices/cables, repair, ...).

BTW is such a problem/information part of that "last error" feature in the D200 display?  Guess, not.

[ogs]

Many thanks to all that took the trouble to answer!

I put A NUC running ROCK in a fanless akasa case with its Teddy Pardo power supply right next to the 250 and connected through usb.with a very good cable.The improvement was impressive.
Now I don’t need an audio grade switch with its audio grade power supply and fancy ethernet cables anymore. Only downside: volume does not sync with Roon as it does over ethernet.

If you do get the urge to tweak a ISORegen with the USPCB on that USB link could be worth a try