Glitches in UAC2 while doing playback.

Discussions about USB Audio on XMOS devices
SonnyDK
Member
Posts: 13
Joined: Wed Apr 13, 2016 8:30 am

Glitches in UAC2 while doing playback.

Post by SonnyDK »

Hi

We have a problem with glitches every 20second or so playing 44.1KHz, with higher samplerate the interval is smaller.

We know the hardware works as intended because we have tested the MQA which we use for a project on the same hardware.

The MQA firmware does not have glitches. The UAC2 Version 6.15.2 with patch does have a problem I suspect it is timing or buffer size problem.

We have tried adding :


par
{
set_core_high_priority_on();
/* USB Interface Core */
#if (AUDIO_CLASS==2)

or have changed the buffer size:

/* Maximum USB buffer size (1024 bytes + 1 word to store length) */
#define MAX_USB_AUD_PACKET_SIZE 1028// 516, 2052, 4100, 8196


We have no luck with it. A hint on what could be the problem here, and it is not hardware related, would be very nice.

BR

Sonny


User avatar
aclassifier
Respected Member
Posts: 483
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Post by aclassifier »

I may have the same problem. I pick of samples from the xCore Microphone Array at 48 kHz and sends each sample from tile[0] to tile[1], with the callback task, basically as in AN00219. I discovered that I had regular glitches, or blips in the headset. This appeared some weeks ago, but I didn't notice it before today. When I removed the 90 words "long message" sent across tiles, which competed with the samples output, the blipping almost disappeared. I have other cross-comm there that I assume do the rest of the blipping.

I have attached the task diagram. It's from My Beep-BRRR notes

I guess having all the mics hardware attached to tile[0] pins and the DAC stuff connected to tile[1] may be a weak point in that board's design.

Is there any smart thing to do? I assume breaking it up into one-word or the like messages would help a lot, but any hint is appreciated.

I assume much of this may have been described in xCONNECT Architecture by XMOS.2013/11/14 Rev A?

I can update my blog post with the newest source code if wanted.

If this is not the same problem as described in this thread, tell me, and I'll start a new thread (I found this very new one by search or coincidence).
fig15_219_task_view_beep_brrr_oyvind_teig.pdf
Task diagram
(83.82 KiB) Downloaded 109 times
fig15_219_task_view_beep_brrr_oyvind_teig.pdf
Task diagram
(83.82 KiB) Downloaded 109 times
--
Øyvind Teig
Trondheim (Norway)
https://www.teigfam.net/oyvind/home/
SonnyDK
Member
Posts: 13
Joined: Wed Apr 13, 2016 8:30 am

Post by SonnyDK »

Thanks for the reply.

I will dig into it aclassifier. And get back.

But i had the same suspicion about the problem.

BR

Sonny
User avatar
aclassifier
Respected Member
Posts: 483
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Post by aclassifier »

I have worked more on this. I made a buffer to buffer dac-samples for the headset:
[[combinable]]
void headset_buffer_task (
        chanend ch_headset_in,
        chanend ch_headset_out)
{
    int data_to_dac;
    while (1) {
        select { // needed for [[combinable]]
            case ch_headset_in :> data_to_dac : {
                ch_headset_out <: data_to_dac;
            } break;
        }
    }
}
The reason for this is that it looks to me like the xConnect architecture should be able to keep more than one data stream going across to tile[1] at the same time. So maybe there was something about the to-from addresses here, that prevented them from being separate streams. (By the way, I use xTIMEcomposer 14.4.1 and xC (here).)

Without this buffer task the blip immediately appeared AFTER the "other long" data from tile[0] to [1]. The analogue output was dead for 20 ms.

When I added the buffer task on tile[0] (as combinable), it got worse. The sound also was dead during that "other long" 30 ms data transfer (both directions), plus the 20 ms after.

If I moved the buffer task over to tile[1] there was no dead sound, except a dead phase every 1.0 sec, unrelated to the "other long" message.

So this is more tricky than I thought. I'll chase that 1.0 sec event and see if I can get rid of it all.

I have scope pictures, but it's so related to my code that I guess it's meaningless to publish them here. I'll write a chapter in my blog when/if I have solved it. NO. I'll actually attach two scope pictures of no buffer and buffer in tile[0].

Chan 1 top yellow is getting data at 48 kHz from the decimators, in ..task_a.
Chan 2 pink is when data is sent from ..task_a to ..task_b
Chan3 blue is when task_b (on tile[0] engages in comm with ..task_y (another buffer) on tile[1]. This is the "long other" (because it's not DAC to the headset)
Chan 4 green is 180 Hz (from https://szynalski.com/tone#180,v1) and 40 dB (20 log) gain in my code

What I think I am saying is that this is more complicated than just "blaming" the "other long" transfer of data. But I assume it's something to do with my code and xConnect.

Does it ring a bell for anyone?
Attachments
2022 03 07 19.10 TEST_HEADSET_BUFFER_TASK is 1 - v0623 SDS00018.png
Buffer on tile[0]
(42.19 KiB) Not downloaded yet
2022 03 07 19.10 TEST_HEADSET_BUFFER_TASK is 1 - v0623 SDS00018.png
Buffer on tile[0]
(42.19 KiB) Not downloaded yet
2022 03 07 19.09 TEST_HEADSET_BUFFER_TASK is 0 - v0623 SDS00020.png
No buffer
(38.55 KiB) Not downloaded yet
--
Øyvind Teig
Trondheim (Norway)
https://www.teigfam.net/oyvind/home/
User avatar
aclassifier
Respected Member
Posts: 483
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Post by aclassifier »

Take all of the above with a pinch of salt. The blue pulse also includes som I2C on tile[0]. Sorry. I will be back. Ø

- - -

Update 9Mar2022: The "large" chunk of data sent across from tile[0] to tile[1] is max 90 words at a time. This seems to take some 3.2 us, including some admin messages. This is not where my problem is. Passing mic samples one by one is no problem. xConnect handles this perfectly fine I now think.

However, I still need to have the headset_buffer_task on tile[1] not to hear the blips - provided I I2C write to the display on tile[0] on every 128 ms, after each FFT etc.

If I don't write to the display, the blips are gone, I don't need the headset_buffer_task. So my initial wording wasn't that bad.

Will be back, and then update all of the code to have a look, in my blog note.
--
Øyvind Teig
Trondheim (Norway)
https://www.teigfam.net/oyvind/home/
User avatar
aclassifier
Respected Member
Posts: 483
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Post by aclassifier »

I have issued a ticket to XMOS called "linker or xmap error: blips in sound output switched on and off by adding an unused xassert(false)". XMOS ticket number #183751 (in case you should need to refer to it).

I have found another way to get rid of the blips. Just adding an unused xassert(false) in an empty if/then/else case did it. Or as mentioned, adding that buffer.

See scope pictures, below.

I think it smells some kind of build error, linker or xmap.

I guess I'll close for now. This may have gone too much out of scope for the starting question.
Attachments
v0632 no blip ok SDS00045.png
No blips, unused xassert(false) added. Also like this with the buffer.
(45.1 KiB) Not downloaded yet
v0632 no blip ok SDS00045.png
No blips, unused xassert(false) added. Also like this with the buffer.
(45.1 KiB) Not downloaded yet
v0632 blips not ok SDS00046.png
Blips
(44.97 KiB) Not downloaded yet
v0632 blips not ok SDS00046.png
Blips
(44.97 KiB) Not downloaded yet
--
Øyvind Teig
Trondheim (Norway)
https://www.teigfam.net/oyvind/home/
User avatar
Ross
XCore Expert
Posts: 962
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by Ross »

Code should be glitching like that - did you modify it at all?

What device are you running on? I guess the first step to understand your code is to let us know what you are running on what tile and do you have any additional cores running.

Some sort of task/core/system diagram would be ideal
User avatar
aclassifier
Respected Member
Posts: 483
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Post by aclassifier »

Thanks, Ross, for responding on this!

My first comment above includes a link to the blog post about this, plus also attached a task diagram PDF. (But it might just be too much info in that blog post since it's a project notepad as well..)

I am running on the 7-mic xCORE microphone array board. I hope this error won't appear again. I have seen this kind of behaviour two times before in my 40+ years career in embedded system (including some happy years with occam/transputer). Both times there was a linker error. It was never resolved (by IAR), but I just rewrote the code (which I also did now) and then swept it under the rug. All the stuff I sent with the ticket is still for some time available at https://www.teigfam.net/div/teig_2022_03_11.zip - but it's probably all too much, as I haven't been able to (or not even tried!) to find those 10 lines of code that have the same problem.

The glitches disappeared in two cases, not related at all. One was to insert an xassert(0) in a not used if-case, in the task that picks up the samples from the decimation code on tile[0]. The other was to introduce a buffer in the samples channel from tile[0] to the DAC I2S task on tile[1]. This only worked if the buffer were placed on tile[1], not tile[0].

I write this up as "not explainable" and have gone on with the slightly rewritten code and do cross my fingers.
--
Øyvind Teig
Trondheim (Norway)
https://www.teigfam.net/oyvind/home/
User avatar
Ross
XCore Expert
Posts: 962
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by Ross »

aclassfier, these seem to be too separate issues - one related to USB Audio. Yours is not, correct?
User avatar
aclassifier
Respected Member
Posts: 483
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Post by aclassifier »

> 6Mar2022
> If this is not the same problem as described in this thread, tell me, and I'll start a new thread (I found this very new one by search or coincidence).

I wasn't sure whether the problem was related to USB or some other audio stuff. Even if I see now UAC2 mentioned, which probably is just USB. Sorry
--
Øyvind Teig
Trondheim (Norway)
https://www.teigfam.net/oyvind/home/
Post Reply