1ms glitches in 352K audio over coax Topic is solved

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

1ms glitches in 352K audio over coax

Post by Zed1970 »

Hi All,

We have a product based on the xCore-200 Audio platform being a USB to SPDIF/Coaxial converter with outputs only. No DAC,s or ADCs, no inputs. The coaxial output is capable of running at 352/384 due to a 45/49MHz PLL clock (only used at those rates). The SPDIF/coaxial code is standard SpdifTransmit.xc that comes with the development package. The only tweak is the addition of a switch case for 352/384 which uses the standard SpdifTransmit_1 function but with a 45/49Mhz clock. In all it works well but when listening to any audio at 352/384 there are random clicks. The clicks are random often 20/30+ seconds apart but there's at least 1/2 dozen per song. Nothing specific about the timing, can be in a quiet or dynamic patch of music.

Attached is a screenshot of the click recorded in Audacity, as you can see it's about 1ms in duration and the audio wave flat-lines during that period.

Any comments would be appreciated.

Thanks
You do not have the required permissions to view the files attached to this post.
View Solution
User avatar
akp
XCore Expert
Posts: 580
Joined: Thu Nov 26, 2015 11:47 pm

Post by akp »

Does the problem occur with Windows, Linux, and Mac?
mmar
XCore Addict
Posts: 134
Joined: Fri Jul 05, 2013 5:55 pm

Post by mmar »

You need recordings spdif signal and no audio. How audio receiver you use? Seems as your receiver lost LOCK to signal.
Zed1970
Active Member
Posts: 55
Joined: Tue Oct 15, 2019 10:36 am

Post by Zed1970 »

@ apk - Audiophile Linux headless server and we've tried lots of other DACs and it's only this one. If your're thinking a possible USB/ALSA interruption then we'd probably see it on other audio rates as well but we don't.
@ mmar, recording with no audio just show a flat line like my glitch..
User avatar
akp
XCore Expert
Posts: 580
Joined: Thu Nov 26, 2015 11:47 pm

Post by akp »

Do you have a method to determine if your SPDIF receiver is losing lock? I would say the following are the most likely:
1. SPDIF transmit loop can't run at 45 MHz. Try setting core to high priority and/or rewrite in hand optimized dual issue assembly
2. Whatever is feeding the chanend can't run at 352 kHz stereo. Seems less likely. But probably fixable by setting high priority if you have > 5 active cores
3. If the channel crosses a tile boundary perhaps the switch matrix is in use. You could try a streaming chanend.

Writing in hand optimized dual issue assembly can speed things up substantially in my experience. Maybe a factor of two or more.
Zed1970
Active Member
Posts: 55
Joined: Tue Oct 15, 2019 10:36 am

Post by Zed1970 »

Thanks for the suggestions. I'm efficient in general micros and embedded Linux but not with the xmos; so 1) how do I up the core priority? And 2) what is 'optimised dual issue assembly?' I have a lot of assembler experience so just a few pointers on what you mean would be appreciated (perhaps a link or something).
User avatar
akp
XCore Expert
Posts: 580
Joined: Thu Nov 26, 2015 11:47 pm

Post by akp »

To set a core to high priority mode, simply call the intrinsic set_core_high_priority_on() e.g. at the beginning of the spdif_tx() thread
You'll also want to ensure you compile with -O3, and ensure you don't set -mno-dual-issue for the SpdifTransmit.xc
This will compile the fastest possible code from the xc file because it will be fully optimized and it will try to run the core in dual issue mode. But it might not be as efficient as assembly.

The CPU can run in single issue (one instruction per clock) or dual issue (two instructions per clock). You will have to read the XS2 ISA manual to really get this. There are two instruction lanes: a resource lane and a memory lane. Some instructions can run in the resource lane only. Some can run in the memory lane only. Some can run in either. And some take both lanes. https://www.xmos.ai/file/xs2-isa-specification/

Here is some very good dual issue assembly, the rgmii receive thread: https://github.com/xmos/lib_ethernet/bl ... i_rx_lld.S

You can also get some help searching around this forum. But basically what I do is compile some xc code that does what I want, then I view the output listing (using xobjdump) and start with that as an assembly prototype. If you compile it as dual issue you will see a lot of nops where the compiler couldn't figure out how to make two useful instructions fit in a dual instruction bundle (dual instruction bundles look like {instruction 1; instruction 2}). Then I optimize the heck out of it.

So, try to get as many dual instruction bundles as possible fully used, and of course use other assembly optimization techniques that are known to the cognoscenti. There may also be ways to improve the algorithm itself. Of course that would be good to do first in xc if possible and then go to assembly to optimize your improved algorithm.
Zed1970
Active Member
Posts: 55
Joined: Tue Oct 15, 2019 10:36 am

Post by Zed1970 »

That's a great help, good info! Off down the rabbit hole..

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

Post by akp »

Good luck! Let me know how it works out. Caveat: there is no guarantee of success with these things, I could be dead wrong on your problem. :-)
Zed1970
Active Member
Posts: 55
Joined: Tue Oct 15, 2019 10:36 am

Post by Zed1970 »

Will do.