This issue shows up as either noisy data in the device USB output or the ch0 and ch1 outputs look like they've been swapped.
This only happens when recording the very first time after enumeration. If I stop and restart recording, the problem always gets fixed.
On looking at the Beagle trace of the first recording after enumeration, I notice that before the EP1 OUT transfers start, the EP1 IN size is 128 bytes, which is incorrect. The expected nominal size is 384 bytes. The EP1 IN size becomes 384 only after the first EP1 OUT transfer, since once OUT transfers start the OUT size is copied to IN in the USB driver.
The 128 bytes size is wrongly calculated in tud_audio_rx_done_post_read_cb(). If 128 bytes is the size to be sent over USB, the data size to be read from the pipeline output is then calculated as 128/3 = 42 (16KHz pipeline, 48KHz USB), which is not a multiple of 4. So for 32bit USB cases, this ends up with the interleaved channel samples getting out of sync.
This can be seen in the trace below, where the 2nd channel is always 0x12345678. The 128 bytes frames look like this:
And the 384 bytes frame look like this:
We can see, how the 384 bytes frame wrongly starts with 0x1234
https://xmosjira.atlassian.net/browse/AP-155
This issue shows up as either noisy data in the device USB output or the ch0 and ch1 outputs look like they've been swapped. This only happens when recording the very first time after enumeration. If I stop and restart recording, the problem always gets fixed.
On looking at the Beagle trace of the first recording after enumeration, I notice that before the EP1 OUT transfers start, the EP1 IN size is 128 bytes, which is incorrect. The expected nominal size is 384 bytes. The EP1 IN size becomes 384 only after the first EP1 OUT transfer, since once OUT transfers start the OUT size is copied to IN in the USB driver.
The 128 bytes size is wrongly calculated in tud_audio_rx_done_post_read_cb(). If 128 bytes is the size to be sent over USB, the data size to be read from the pipeline output is then calculated as 128/3 = 42 (16KHz pipeline, 48KHz USB), which is not a multiple of 4. So for 32bit USB cases, this ends up with the interleaved channel samples getting out of sync.
This can be seen in the trace below, where the 2nd channel is always 0x12345678. The 128 bytes frames look like this:
And the 384 bytes frame look like this:
We can see, how the 384 bytes frame wrongly starts with 0x1234