problem on XP_SKC_SU1 with CODEC_MASTER=1

[hushange]

i have a board XP_SKC_SU1, i want to set XMOS as I2S slave so i setting CODEC_MASTER=1 in customedefines.h of app_usb_and_skc_su1.
but when i run this app on XMOS, the linux host pc print some error about usb audio, also can't play music:
usb 2-1.2: new high-speed USB device number 80 using ci_hdrc
usb 2-1.2: parse_audio_format_rates_v2(): unable to find clock source (clock -71)
usb 2-1.2: parse_audio_format_rates_v2(): unable to find clock source (clock -71)
usb 2-1.2: cannot get ctl value: req = 0x83, wValue = 0x201, wIndex = 0xa00, type = 4.

if i reset CODEC_MASTER=0, the skc_su1 can work well.

is there someone can supply some clues?

many thanks.

[xsamc]

Hi hushange,

Which version of the USB Audio firmware are you running on your board when you make the change? Is it the same version as when the xCORE is master?

Out of interest, have you tested your change on a host running a different OS?

Cheers,
Sam

[hushange]

Hi hushange,

Which version of the USB Audio firmware are you running on your board when you make the change? Is it the same version as when the xCORE is master?
---- my firmware version is 6.15.2. my xTIME version is 14.2.1.

Out of interest, have you tested your change on a host running a different OS?
---- now there is some new found. i have test original version of USB Audio firmware(6.15.2).
the app_usb_aud_sck_su1 can work well on XP-SKU-SU1 both CODEC_MASTER=0 and 1.
but in the mode CODEC_MASTER=1, if i don't config CODEC chip to generate MCLK BCLK LRCLK in fuction AudioHwConfig of file audiohw.xc, the linux host will print the the following error the same as some days ago printed:
usb 2-1.2: new high-speed USB device number 80 using ci_hdrc
usb 2-1.2: parse_audio_format_rates_v2(): unable to find clock source (clock -71)
usb 2-1.2: parse_audio_format_rates_v2(): unable to find clock source (clock -71)
usb 2-1.2: cannot get ctl value: req = 0x83, wValue = 0x201, wIndex = 0xa00, type = 4.

so my question is:
1. whether the linux host init the XMOS AUDIO card is related with MCLK BCLK LRCLK?
2. whether there is some way to init XMOS AUDIO card well with no MCLK BCLK LRCLK, because we will delay a long time to config CODEC chip to generate this signals after power on.

Cheers,
Sam

[xsamc]

---- now there is some new found. i have test original version of USB Audio firmware(6.15.2).
the app_usb_aud_sck_su1 can work well on XP-SKU-SU1 both CODEC_MASTER=0 and 1.
but in the mode CODEC_MASTER=1, if i don't config CODEC chip to generate MCLK BCLK LRCLK in fuction AudioHwConfig of file audiohw.xc, the linux host will print the the following error the same as some days ago printed:
usb 2-1.2: new high-speed USB device number 80 using ci_hdrc
usb 2-1.2: parse_audio_format_rates_v2(): unable to find clock source (clock -71)
usb 2-1.2: parse_audio_format_rates_v2(): unable to find clock source (clock -71)
usb 2-1.2: cannot get ctl value: req = 0x83, wValue = 0x201, wIndex = 0xa00, type = 4.

so my question is:
1. whether the linux host init the XMOS AUDIO card is related with MCLK BCLK LRCLK?
2. whether there is some way to init XMOS AUDIO card well with no MCLK BCLK LRCLK, because we will delay a long time to config CODEC chip to generate this signals after power on.

Please correct me if I've misunderstood, but it sounds like the firmware works correctly when unmodified in both CODEC_MASTER mode and with the xCORE as master.

The AudioHwConfig() function in app_usb_aud_skc_su1/src/extensions/audiohw.xc is used to select the MCLK rate and configure the CODEC. This function will be called whenever the host sets the sample rate, which should happen at startup.

I'm not sure I understand what you're trying to achieve, do you want to configure the clocks later to reduce the device startup time?

[hushange]

Hi Sam:

many thanks for your reply.

Please correct me if I've misunderstood, but it sounds like the firmware works correctly when unmodified in both CODEC_MASTER mode and with the xCORE as master.
----you are right, the unmodified firmware works well for us.

The AudioHwConfig() function in app_usb_aud_skc_su1/src/extensions/audiohw.xc is used to select the MCLK rate and configure the CODEC. This function will be called whenever the host sets the sample rate, which should happen at startup.
----yes, i understand your means. but our product has some diffrience. when host set the sample rate, it is MCU not XMOS to select the MCLK rate and configure the CODEC. so our XMOS need to wait I2S signal(MCLK BCLK LRCLK) become ready. if the waiting is more than 3000ms, then the linux host will print error. so whether there is a method to let linux can init XMOS well if I2S signal delay more than 3000ms befor becoming ready?

[xsamc]

The AudioHwConfig() function in app_usb_aud_skc_su1/src/extensions/audiohw.xc is used to select the MCLK rate and configure the CODEC. This function will be called whenever the host sets the sample rate, which should happen at startup.
----yes, i understand your means. but our product has some diffrience. when host set the sample rate, it is MCU not XMOS to select the MCLK rate and configure the CODEC. so our XMOS need to wait I2S signal(MCLK BCLK LRCLK) become ready. if the waiting is more than 3000ms, then the linux host will print error. so whether there is a method to let linux can init XMOS well if I2S signal delay more than 3000ms befor becoming ready?

Ah! While the xCORE is in the call to AudioHwConfig() it will be NAKing the USB control endpoint EP0 - this ensures that the host knows when the USB Audio device has completed its configuration change and it is safe to open an audio stream at the new sample rate. EP0 can only be NAKed for 1 second according to the USB specification, which is very likely the reason you are seeing Linux give up after 3.

If it's not possible to reduce the time it takes the MCU to configure the CODEC, perhaps the MCU could hold the xCORE in reset initially until it is ready?

Cheers,
Sam

[hushange]

yes, now we just plan to keep xmos in reset state until I2S signal be ready.

thank you again, Sam.

[hushange]

Hi Sam:

trubble you again^.^
another question:
the firmware supports to set XMOS as I2S slave.
in this situation, whether the firmware also supports to set XMOS as DSD slave?
because in firmware 6.15.2, I2S shared some ports with DSD.

many thanks
hu yongfa

[xsamc]

Hi Sam:

trubble you again^.^
another question:
the firmware supports to set XMOS as I2S slave.
in this situation, whether the firmware also supports to set XMOS as DSD slave?
because in firmware 6.15.2, I2S shared some ports with DSD.

many thanks
hu yongfa

Hi hushange,

Do you mean DSD input, when you say DSD slave?

For DSD output, I don't think this will work completely correctly without a little modification to the code. You'll have to ensure that the all the clocks are correctly aligned so that your DSD output is not running behind.
I hope this points you in the right direction.

Cheers,
Sam

[hushange]

Do you mean DSD input, when you say DSD slave?
----xmos output dsd data, but codec supply bclk.
----just like codec is dsd master, receive data from xmos, whether this can be implemented?