Periodic popping noise on XUF208-128

[infiniteimprobability]

The 1001 vs 1003 Hz is interesting. Again, it feels like an explicit asynch feedback issue but I don't understand how that can go wrong on a single tile system, unless bug has been introduced.
Is it teh same behaviour on other hosts (MACOS or Windows?)

Can you make precise measurements of the MCLK, BCLK and LRCLK frequencies and report back?

I think you firmware guy will need to get involved - you need to understand what changes have been made because one of the will be the cause of this issue.

[jimvaughan]

These are the clock frequencies - the 24MHz goes to pin 58 (CLK) and the 24.576MHz goes to pin 64. Is there anything else I should check?

[infiniteimprobability]

Yes - that is just MCLK and SYSCLK which both look absolutely fine, although as they are inputs there is not much to go wrong if the oscillators are working so al you're really doing is measuring the PPM of the osc..

The most important one is BCLK but it would be good to see BCLK and LRCLK to understand what rate the I2S device thinks it's running at. If these are bang on 3.072MHz and 48000kHz at 48k then it's time to understand the firmware changes made in more detail

[jimvaughan]

This is in the output of dmesg:

[ 8.257450] usb 1-4: parse_audio_format_rates_v2(): unable to find clock source (clock -19)

Is it related? Is it possible to discuss this on the phone with someone at XMOS?

[infiniteimprobability]

Could be related but difficult to say. It would be interesting to see what a USB analyser makes of the get range request from the host (which is the one that informs it of sample rates). However if it runs but just pops occasionally then that doesn't necessarily stack up. My sense is telling me that the explicit feedback calculation is wrong and the host is being told to send too many/too few samples each time. The normal culprit for that would be MCLK but in your case it's single tile so MCLK is shared with the I2S generation which sounds like it's working. However, it would still be interesting for you to report the BCLK and MCLK frequencies.

I would recommend doing a diff of your code against the reference design which does not exhibit this issue and see what changed.

Is it possible to discuss this on the phone with someone at XMOS?

- Personally I answer questions in my spare time (best effort when I get a moment from my day job) and wasn't planning on providing telephone support - you could try contacting the distributor you buy the chips from..

[infiniteimprobability]

For anyone reaching this thread...
There seems to be an issue using implicit feedback (where rate is calculated from input stream in USB audio) with some linux/Intel hosts.

The solution is to enable explicit feedback in the device (enables a explicit feedback on the output endpoint.

Do this using -DUAC_FORCE_FEEDBACK_EP=1 in the Makefile