Fix UAC encoding, update example.

[HiFiPhile]

Describe the PR
Currently interleaved copy in UAC2 is bugged with wrong stride, resulting samples become scrambled if encoding/decoding is enabled.

#2256, maybe #1722

Additional context
audio_4_channel_mic example use identical sample for all channels, makes the problems less obvious, now it has been updated to output different waveforms each channel.

[HiFiPhile]

@PanRe could you take a look when you are free ?

It's tested on stm32g0b1 and stm32f407.

[PanRe]

Thanks a lot for fixing the bug! Nice work as usual!

[PanRe]

In real world ;)

[HiFiPhile]

@PanRe Thanks for your quick return :)

I'll try to optimize IN transfer data flow in a following PR.

For TYPE-I format the allowed sample in each packet is n_avg+-1, for example 48kHz with a FS device gives 47~49 samples per packet.

---

Currently it always try to send all the data in FIFO. If we take example of a 48 sample length I2S buffer, who writes all samples to UAC FIFO every 1ms:

• If I2S clock is quicker packet length will be 48 48 48 49 48 48... which works
• If I2S clock is slower, packet length will be 48 48 48 0(or other low value) 48 48 48 48..., low value could be discarded by the host resulting gap in recording.

---

What I'm think is increase IN FIFO size to at least 4*packet size:

• If FIFO level is less than 25%, use packet length of n_avg-1 if enough data, otherwise 0.
• If FIFO level between 25%-75% use packet length of n_avg
• If FIFO level above 75% use packet length of n_avg+1

SO the above example packet length becomes 48 48 48 47 48 48 48 47.

[PanRe]

Interesting idea, but isn't that what you already implemented in one of your projects? I remember you mentioned something like that for the feedback value calculation?

Nevertheless, I like the idea. However, it introduces a lag and some users might not want that. I know, it is hard to get it working without some kind of buffering. How about defining a minimum buffer fill level? The higher it is, the more robust it gets. For users which don't want a buffering, they can set the fill level to zero.

Do we need to need to modify the feedback value depending on the buffer settings?

[HiFiPhile]

Interesting idea, but isn't that what you already implemented in one of your projects? I remember you mentioned something like that for the feedback value calculation?

It was for OUT transfer, in that case user code has the responsibility to calculate feedback correctly. For IN transfer the feedback is implicite, simply determined by how much data is sent.

After thinking current code only support fixed sample rate, it's necessary to calculate n_avg based on sample rate to let multi-rate work. For example in 48k & 96k case the FIFO size will be 96+1, when 48k is chosen sent packet could be 96 0 96 0....

However, it introduces a lag and some users might not want that.

As the FIFO will be filled in to 50% in average so there will be an additional delay of 1ms for FS or 125us for HS. Compared to OS's latency it's mostly neageible.

For users which don't want a buffering, they can set the fill level to zero.

The only case is when I2S clock perfectly synced with USB clock, like current examples where data is simply looped back.

[PanRe]

I see! I think it is a great idea!

[hathach]

awesome, great work as usual 👍 👍