USB Audio Reference Design 2.0 Performance.

[AudioBoy]

Alex, I use evaluation driver from XMOS site.
Thank you for information.

[Ross]

Hi Ross,

of course, MCLK is need for operation, and nobody think that w/o power at isolated part the system will operate.
I asked something else - do we need to have backup internal MCLK at CPU side, if the main MCLK (at isolated side) is not powered on?
If the solution with 2 oscillators, multiplexer and mclk-detector is must?
Or in case of MCLK missing, the system will wait for isolated part to be powered on?

I'm not sure exactly what you mean to be honest.

However, I wouldn't advise swapping clock sources apart from at a sample change request from the host - they won't be the same frequency and could you throw off feedback calculation in the device and host.

The MCLK input to the XMOS device isn't required if the device isn't doing USB audio at the time i.e. if it is performing some other function, in a power-down state or similar.

[AlexAdvice]

I'm talking about this device:
http://www.diyaudio.com/forums/digital- ... eamer.html

The author want to use jitter clean MCLK, located near the DAC. All galvanically isolated ftom the USB part. On PC side he detect external MCLK, and switch between the external and internal clock.
Tranisent period is not so important.
Internal clock used only when the external board is turned off, so nobody hear the music.
All these afforts - to do not disconnect USB XMOS interface from the PC, byt to have the possibility to turn on/of the power of DAC+Clock.

[mhelin]

As far as I can understand the explicit feedback is not an absolute must with the full-duplex audio, and some drivers (Thesycon I think) don't require async feedback at all. It would be nice if the USB Audio 2.0 XMOS firmware would have something like a compiler option for disabling the feedback so that the clocking would be much easier to implement (and the audio performance also would be a lot better because of less high frequency signal on PCB polluting the analog part, PSU's, air etc.).

Also at least Apple recommends using implicit feedback:

https://developer.apple.com/library/mac ... 1-TNTAG4_3

"Note: We recommend using implicit feedback when possible because it conserves both device and host resources, and increases feedback precision."

[Ross]

As far as I can understand the explicit feedback is not an absolute must with the full-duplex audio, and some drivers (Thesycon I think) don't require async feedback at all. It would be nice if the USB Audio 2.0 XMOS firmware would have something like a compiler option for disabling the feedback so that the clocking would be much easier to implement (and the audio performance also would be a lot better because of less high frequency signal on PCB polluting the analog part, PSU's, air etc.).

While your statement that "explicit feedback is not an absolute must with full-duplex audio" is true you still need a MCLK input for "implicit" feedback since you need to size the packets transmitted to the host - essentially a feedback value is generated internally and used to size the packets. Essentially the feedback is implicit in the input stream. The statement "some drivers (Thesycon I think) don't require async feedback at all" is therefore incorrect (unless "aysnc" was a typo..)

Btw I assume these DAC projects are output only, which still required an explicit feedback endpoint.

Most DACs are going to need a high-frequency master clock to operate anyway, so I'm a bit confused as to your point... If they don't they you have probably lost all benefit of an asynchronous system i.e. a high-quality local master clock source.

Also at least Apple recommends using implicit feedback:

https://developer.apple.com/library/mac ... 1-TNTAG4_3

"Note: We recommend using implicit feedback when possible because it conserves both device and host resources, and increases feedback precision."

It's really nice of Apple to recommend that since the reason we still have an explicit feedback pipe when input is enabled is because their driver didn't support it until not so long ago! ;)

The Thesycon driver has always used the input stream where available, I mean, why wouldn't you?!