USB audio framework and sample rate conversion (lib_src) issue

Technical questions regarding the XTC tools and programming with XMOS.
Post Reply
alexjaw
Active Member
Posts: 35
Joined: Wed Jan 24, 2018 9:13 am

USB audio framework and sample rate conversion (lib_src) issue

Post by alexjaw »

In the xmos forum thread https://www.xcore.com/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
reference
(497.71 KiB) Not downloaded yet
reference-96k24-to-96k24.jpg
reference
(497.71 KiB) Not downloaded yet
distorted-96k24-to-96k24.jpg
sync failure
(506.84 KiB) Not downloaded yet
distorted-96k24-to-96k24.jpg
sync failure
(506.84 KiB) Not downloaded yet


User avatar
akp
XCore Expert
Posts: 578
Joined: Thu Nov 26, 2015 11:47 pm

Post by akp »

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