UAC2: Can the Internal clock source be controlled by device?

If you have a simple question and just want an answer.
CalebRoberts
Junior Member
Posts: 4
Joined: Wed Feb 03, 2016 10:20 pm

UAC2: Can the Internal clock source be controlled by device?

Postby CalebRoberts » Wed Feb 03, 2016 10:52 pm

I've been attempting to modify the current release of the USB Audio reference code so that there is one sample rate clock source - that can be controlled by the device ( and perhaps not by the host).

In the XMOS reference project, the first clock source is "internal", is hard-coded to always report "valid" and its sample frequency is only controlled by the host. If there are S/PDIF or ADAT receivers, a second (and third) clock source is exposed to the host and if the host selects (user action) one of the other clock sources then the sample frequency is determined by the S/PDIF or ADAT source. The device synchronizes to that input FS and reports changes of FS and validity to the host by issuing an interrupt.

I made these changes:
With one clock source, the descriptors report that it can be controlled by the device. When the device changes its sampling frequency it reports this to the host via interrupt.

Results: device's sample rate changes are acknowledged by mac OSX - but not the Thesycon driver.

I'm trying to determine whether the Thesycon driver precludes device control of the first clock source. I haven't found documentation indicating so. But, in the development of a product a few years ago, I seem to recall encountering such a limitation. I didn't document it for myself at that time and I can't remember.

Can you offer info from experience or documentation that I haven't found? thanks
User avatar
Ross
XCore Expert
Posts: 768
Joined: Thu Dec 10, 2009 9:20 pm

Postby Ross » Thu Feb 04, 2016 4:21 pm

When do you actually switch the sample rate of the device? Is there a point in time when you have switched by the host doesn't know yet?
CalebRoberts
Junior Member
Posts: 4
Joined: Wed Feb 03, 2016 10:20 pm

Postby CalebRoberts » Thu Feb 04, 2016 4:21 pm

Ross wrote:When do you actually switch the sample rate of the device? Is there a point in time when you have switched by the host doesn't know yet?


The sample rate change works just the same as if it were a spdif_rx change. I'm not sure I get what you're asking about - but I think the answer is "no".

The sample rate changes just the same as if the spdif_rx changes. Clockgen detects the change, sends an interrupt message for ID_CLKSRC_INT - to the buffer thread. This all the same as the reference code - except that it interrupts for ID_CLKSRC_INT. The stock clockgen won't interrupt for the interrupt because FS changes to internal clock are only initiated by audiorequests.xc.

I modified audiorequests to pass sample frequency and validity queries to clockgen instead of just responding in place (always valid, always the FS previously set by the host).

Since it works as I planned with OSX and not the THS driver, I suspect that THS driver may not support device changing the first clock source.
User avatar
larry
Respected Member
Posts: 275
Joined: Fri Mar 12, 2010 6:03 pm

Postby larry » Wed Feb 17, 2016 1:32 pm

If Thesycon driver can indeed only handle changes in "primary" clock source, but not "secondary", maybe it's possible to swap IDs of clock sources in descriptor so the clock source that's changing is the "primary" one.
User avatar
Caleb
Active Member
Posts: 56
Joined: Thu Apr 04, 2013 10:14 pm
Contact:

Postby Caleb » Wed Feb 17, 2016 1:32 pm

Hi Larry, You have this backwards. The THS driver seems to only accept device changes to FS from the "secondary" clock source - not the "primary". I described this situation to the Thesycon.de support web page and I response confirming: "Currently, this is not supported by our driver." So I requested they consider this as a new feature - to bring it in line with OSX.

larry wrote:If Thesycon driver can indeed only handle changes in "primary" clock source, but not "secondary", maybe it's possible to swap IDs of clock sources in descriptor so the clock source that's changing is the "primary" one.
MaximLiadov
Member++
Posts: 23
Joined: Mon Apr 16, 2018 9:14 am

Postby MaximLiadov » Sun Nov 04, 2018 2:17 pm

Any updates on this topic since 2016 year? We faced with the same issue. Seems to be no way to change XMOS frequency mode based on incoming S/PDIF input signal. As XMOS device could be used in stand-alone mode, without USB host device, it's important to change frequency mode automatically or we get damaged sound on output. Working source code example with interrupt message ID_CLKSRC_INT also would be nice. I found some similar topics with no solution yet.
MaximLiadov
Member++
Posts: 23
Joined: Mon Apr 16, 2018 9:14 am

Postby MaximLiadov » Tue Nov 06, 2018 12:58 pm

Even if we use an external hardware SPDIF receiver (AKM, CS) with I2S output, instead of XMOS spdif_rx module, we still need to change current XMOS audio sampling mode on the fly to implement SPDIF IN bit accurate playback, automatically for any incoming SPDIF signal. We need to make it possible with USB host connected, by forcing this changing from firmware level, and especially in stand-alone mode, without USB host connected. Any clue or working solution? That looks like THE VERY common task when you are trying to add SPDIF input to XMOS based DAC. I found many similar topics in the forum with no good solution. I see the best practice in tons of XMOS DACs is in avoiding XMOS and directly connecting SPDIF receiver and DAC with a hardware switch, but I don't like this brute force way, that comes from desperation. I need to use XMOS and SPDIF IN together for many reasons.

Who is online

Users browsing this forum: No registered users and 29 guests