tud_audio_read() doesn't return the right value after merge #2739

[ra1nb0w]

Operating System

Linux

Board

STM32H563

Firmware

custom build

What happened ?

after c60934e tud_audio_read() returns only half of the requested bytes.
reverting the merge it returns the right bytes.
I read the commits but nothing obvious to me was found.

How to reproduce ?

uint16_t audio_read_bytes = tud_audio_read(&audio_buffer[0U], AUDIO_BLOCK_SIZE * sizeof(int16_t));

Debug Log as txt file (LOG/CFG_TUSB_DEBUG=2)

tinyusb.log.txt

Screenshots

No response

I have checked existing issues, dicussion and documentation

• I confirm I have checked existing issues, dicussion and documentation.

[ra1nb0w]

with latest commits the value is correct. But it is non constant like before the rework.
Instead, the mic is completely unusable now. It is constantly in underrun (tested on linux) but the value returned by tud_audio_write is stable and correct.
I hope these feedback are useful.

[HiFiPhile]

@hathach I'd a git bisect, it looks like d680424 breaks ISO IN transfer.

[hathach]

thank @ra1nb0w and @HiFiPhile, sorry I indeeded didn't tested the ISO since I am still not familliar with audio yet. I mostly tested other examples running hil_test.py locally (also added an g0 (32-bit 2048 KB), f0 (1KB), ch32 (512B) to my hil pool to make sure my rework does not break things.

which example you are testing with ? I can use analyzer to capture but can you help a bit to write a python the script to read its payload count, that would make thing easier/faster. Will try to fix this asap.

[HiFiPhile]

@hathach
For H5 the fix is simple, just a buf_id thing.
https://github.com/HiFiPhile/tinyusb/tree/fsdev_iso_fix

which example you are testing with ? I can use analyzer to capture but can you help a bit to write a python the script to read its payload count, that would make thing easier/faster

It's the audio_4_channel_mic example, since the data is a stream it is a little tricky to validate the output with a script, but if you run plot_audio_samples.py and a get a clean output (sinus, square, saw wave) it should be good.

---

There is another tricky issue on older device, I'm trying to figure it out on L0.

[hathach]

@HiFiPhile got it, running that script is good enough. No worries, I also have G0 and H5 which has 32-bit bus (2K USB SRAM). I will do some testing, bi-set and backtrack. It is probably the buffer toggle issue.

[HiFiPhile]

False alarm for L0, I just forgot disable DEBUG so the timing was all wrong...

@hathach since you are working on it you can integrate the changes if you want.

[hathach]

thank you @HiFiPhile , it seems to fix the issue, it is easy to miss epreg bit manipulation :). Though on Linux, the plot does not look as good as your screenshot, but that is no problem, I will find a way to verify these value with a script later so that we could include them in the hil test.

[ra1nb0w]

fixed. Thank you very much guys!

the plot is probably the same, the issue is the (horizontal) time scale.