Sample rate conversion 352/384K to 192K

Sub forums for various specialist XMOS applications. e.g. USB audio, motor control and robotics.
Zed1970
Member++
Posts: 28
Joined: Tue Oct 15, 2019 10:36 am

Sample rate conversion 352/384K to 192K

Postby Zed1970 » Mon Nov 09, 2020 12:49 pm

Hi,

Our product (based on xCORE-200 Multichannel Audio Platform) only has two outputs, SPDIF optical and coaxial -there is no I2S whatsoever. The SPDIF optical runs up to 192k and the coaxial up to 352/384k. As the product advertises itself as 352/384k capable over USB we have an urgent requirement to convert 352/384k down to 192k so the user can still use the optical interface. Both interfaces need to at least render audio at all rates. The rate conversion files on xmos git appear to have a maximum rate of 192k, it is possible to up the maximum rate to 352/384k then convert down to 192k?

So cutting a long winded story short, we're after a 352/384k to 192k rate converter..

Thanks.
fabriceo
Active Member
Posts: 45
Joined: Mon Jan 08, 2018 4:14 pm

Postby fabriceo » Mon Nov 09, 2020 1:18 pm

Hi

guess you are using the standard SPDIF_TX library ?
were you able to configure it to render 352/384k on coax ? ? ?
is the SDPIF task running on tile1 (like USB) or tile0 (like Audio I2S) ?
do you have 2 tasks and 2 one-bit port for the coax and the optical or just one for both ?

when it comes to SRC, I ve made one for my application, to down sample 352/384/176/192 to 88/96 respectively, with a pretty simple approach : moving average to divide by 4 or 2 and then FIR at 88/96 to remove as much aliasing as possible.

for FIR 88/96k on stereo, I went ok with 96 points on each channels (after the moving average), all that done in the Decouple Handler (interrupt) before sending data to Audio task (just after in fact, delayed by 1 sample).
for 176/192k, I ve made some tests and I got only 40 taps FIR for 2 channels driven in one task and then this is not enough to clean the signal.

So you may have to consider 2 specialized task (1 for left , 1 for right), receiving data from Decouple Handler via dedicated channels, processing Average by 2 and then 176/192k FIR 96 taps-ish. the output will directly drive the spdif channel.

the code for averaging is no brainer, and I took the code for FIR directly from the lib_dsp available on GitHub, no brainer also.

with same approach I also made FIR to decimate DSD Native and DoP signal , so XMOS-200 is quite capable :)

good luck, keep us posted
User avatar
akp
Respected Member
Posts: 462
Joined: Thu Nov 26, 2015 11:47 pm

Postby akp » Mon Nov 09, 2020 3:09 pm

Like fabriceo says if you can convert the 352 to 176 that will be substantially easier than converting it to 192 since it's just a synchronous decimate by two that will work for either 352 or 384 input. Otherwise you'll need a more sophisticated SRC which would still work but it won't be as simple.

I suspect you can do stereo FIR decimator by 2 relatively easily, but I'm not sure if you can do it in a single task with a 384k stereo input. I haven't tried it. fabriceo uses a hybrid approach of a short FIR then a longer FIR. What I wonder is, fabriceo, did you try dsp_filters_decimate ? That would seem to be the obvious solution rather than the hybrid since it should be optimized to not calculate the unneeded outputs.
fabriceo
Active Member
Posts: 45
Joined: Mon Jan 08, 2018 4:14 pm

Postby fabriceo » Fri Nov 13, 2020 7:41 am

akp wrote:
Mon Nov 09, 2020 3:09 pm
What I wonder is, fabriceo, did you try dsp_filters_decimate ? That would seem to be the obvious solution rather than the hybrid since it should be optimized to not calculate the unneeded outputs.
Hi,
when you look in the code of dsp_filters_decimate, its basically a FIR but moving state data (Xn..) by group of N (decimation factor) instead of one by one. The overhead in the code is from my point of view too big compared to a basic average filter by N and then optimized FIR at FS. that said, rewriting the code with concept of circular buffer would be much better to avoid the data transfer of N sample at each cycle. to be investigated
Zed1970
Member++
Posts: 28
Joined: Tue Oct 15, 2019 10:36 am

Postby Zed1970 » Thu Nov 26, 2020 9:38 am

Hi Fabriceo,

Thanks for you replay and apologies for the delay in responding; it been extremely busy. To answer your questions:
1) guess you are using the standard SPDIF_TX library ? Yes
2) were you able to configure it to render 352/384k on coax ? ? ? Yes, used the PLL to give 48-50MHz then used the 192/176 routines (SpdifTransmit_4)
is the SDPIF task running on tile1 (like USB) or tile0 (like Audio I2S) ? AUDIO_IO_TILE 0
do you have 2 tasks and 2 one-bit port for the coax and the optical or just one for both ? The same task does both. At the point where the hardware is feed both transceivers are written too i.e. SpdifTransmit_4().... partout(optical, 16, encoded_byte); partout(coaxial, 16, encoded_byte); I took this approach because to change from coax to optical it's just a pin tweak in the sample xk-audio-216-mc.xn meaning it uses the same code; so I just feed both outputs simultaneously. It's probably not the best but we are still learning..

So what would you suggest is the way forward regarding this down conversion challenge?

Thanks.

Who is online

Users browsing this forum: No registered users and 0 guests