More than two open UAC2 devices causes problems on the 3rd

[hannescam]

Hi,

I have an ESP32-P4 where I have setup 3 audio outputs among 4 inputs using a slightly modified version of TinyUSB, all of these interfaces need to work at the same time.

The four inputs are all working flawlessly but if I playback on all three outputs on the same time the last one on which I started playback only periodic clicks comes out of the speaker (about every 32 ms) which I have been unable to resolve.

What I have tried:

• disable the inputs to reduce CPU load - no change
• decrease sampling rate 192 KHz -> 96 KHz - no change
• VM with Windows 10 - all outputs/inputs show up as broken with problem ID 0xA and problem status of 0xC000009C
• my PC with Fedora 44 Workstation - the described behavior
• my laptop with Fedora 44 Silverblue - similar behavior but always the first output fails and it fails mute

The FW with the modified version of TinyUSB: MelodyCatcherFW.zip
The FW is still a bit chaotic... I will put it on GitLab once it is working and I have cleaned it a bit up

Thanks for any help...

[hannescam]

Some additional findings:
The clicks occur because data comes in about 2-20 times a second (I have measured calls to the data received callback using a counter) when I measure about 8000 times (no variation) when it's running normally.

[hannescam]

UPDATE:
I have found a small remaining bit of my debugging attempts which prevented enumeration completely (extra = 0 in the ITF enum inside usb_descriptors.c)

Additionally I have tried it on the Raspberry Pi 5 with kernel 6.12.85-0-rpi on PostmarketOS (don't ask why) where all outputs worked except the first activated one after I've activated the last the first (activated) would get dropouts every 1-2 seconds and the TinyUSB data received callback for that output would then be called about 7800 times a second and sometimes also normally (8000 times)

[HiFiPhile]

VM with Windows 10 - all outputs/inputs show up as broken with problem ID 0xA and problem status of 0xC000009C

VM with USB passthrough is known to have issues with ISO transfer, try to find a physical machine.

You can use Wireshark to monitor USB traffic to see if the host send data correctly.

[hannescam]

Thanks,
I will try to get my hands on a Windows machine...
And using Wireshark is a great idea, I have already used it to diagnose issues with the descriptor but didn't think about using it to diagnose this issue.

[HiFiPhile]

Have you tried enabling DMA #define CFG_TUD_DWC2_DMA_ENABLE=1 ?

[hannescam]

No, didn't even know that option existed...
But it fixed the problem!!!!!!
Thanks

But why does it fix this problem?

[HiFiPhile]

DWC2 in general (depend on IP config) has one shared RX FIFO for all OUT endpoints and dedicated TX FIFOs for each IN endpoint. The RX FIFO is sized to 2*maximum packet size of all EPs according to Databook (under NDA).

For transfer types other than ISO, if the RX FIFO is occupied when a new packet arrives then NAK will send to host and the host will launch a retransfer. However since ISO transfer doesn't use ACK mechanism the packet is just lost.

If you want read more about FIFO allocation :)

tinyusb/src/portable/synopsys/dwc2/dcd_dwc2.c

Line 157 in 299c0a5

/* Device Data FIFO scheme

However DMA is not always available:
https://github.com/hathach/tinyusb/blob/master/src/portable/synopsys/dwc2/dwc2_info.md

[hannescam]

Thanks like this it's clear,
and I got lucky that the ESP32-P4 supports DMA otherwise I would have probably needed to redesign the whole project...