USB audio framework and sample rate conversion (lib_src) issue

Technical questions regarding the xTIMEcomposer, xSOFTip Explorer and Programming with XMOS.
alexjaw
Active Member
Posts: 35
Joined: Wed Jan 24, 2018 9:13 am

USB audio framework and sample rate conversion (lib_src) issue

Postby alexjaw » Wed Mar 25, 2020 10:52 am

In the xmos forum thread viewtopic.php?f=26&t=6593, we investigated the possibility to perform sample rate conversion with the USB audio framwork. The outcome became an usb app that demonstrates the functionality of lib_src on the mc eval board, https://github.com/alexjaw/xmos_usb_ssrc_demo. To some extent this code does what was planned for AN00230 - Adding Synchronous Sample Rate Conversion to the USB Audio reference design. Furthermore, it was also shown that it is possible to handle frequencies above 192k, e.g. 352k and 384k.

However, recently I found an issue that I have have not been able to resolve. Of course, this has appeared when we are finalizing a product and where the different parts are tested more thoroughly. This issue can been reproduced in the following way:
Button 1 on the mc board is used to switch between sample rates from 44.1 to 192k (44.1, 88.2, 96, 176, 192, 44.1...). Normally, when switching between different sample rates, everything is just fine. I check the i2s signals coming out from xmos and can observe the status of LR, BT and DATA signals. But from time to time the audio output from the DAC is highly distorted. This happens approximately 1% of the times. It turns out that the i2s data out from xmos in these cases is shifted 1 BT clock cycle. The attached images show 96/24 to 96/24, i.e. 1-to-1 conversion with the problem. The first image is reference i2s LR and DATA out from xmos. The second image is the same material but distorted and the shift of DATA with respect to LR signal is evident.
* USB framework 6.15
* lib_src 1.0.0
* xTimeComposer 14.3
* USB driver TUSBAudio (4.11.0).

Things I have tested:
- print statements in the code (src_manager) does affect the number of occasions that this happens. Suggest that this is a timing issue.
- the app is using the old SOF code in usb_buffer.xc. As long as one is not doing any conversion between 44.1 and 48 domains, it is possible to use the new SOF code. But the problem still happens.
- the documentation for lib_src mentions that SSRC_N_IN_SAMPLES can be increased from 4 to 16 in order to lower the computational burden on the processor. This has been tested and the result was that the number of occasion with bad sync lowered but it did not disappear.
- it's not a problem with the button (debounce or something...). This issue is inherent to the shifting between sample rates.

What I ask for is help to determine if this is a timing problem or if it is a bug in the lib_src code. Where in the lib_src code is it most probable that the sync between DATA and LR might happen. Or might it be src_manger and/or dsp_wrapper (in src/extensions) that is problematic? I have tried to use xscope but have not been able to configure it correctly - it affects the timing too much in order to be used as a debugging tool in this case.

Any comments are highly appreciated,
Alexander
reference-96k24-to-96k24.jpg
distorted-96k24-to-96k24.jpg
You do not have the required permissions to view the files attached to this post.
User avatar
akp
Respected Member
Posts: 466
Joined: Thu Nov 26, 2015 11:47 pm

Postby akp » Wed Apr 01, 2020 9:26 pm

Can you post the exact code used to change sample rates?

Who is online

Users browsing this forum: No registered users and 7 guests