Audio feedback , fifo count and frequency fixed method sends only one message then the EP is busy (resolved)

[Lurcy38]

Hello,
I am confused with the audio Feedback, I tested the method AUDIO_FEEDBACK_METHOD_FREQUENCY_FIXED and AUDIO_FEEDBACK_FIFO_COUNT
I tested using a stm32h7 and stm32h5 with the same result.
I assume that every period of time, we send a feedback message to the host, but it seems that only the first message gets its acknowledge and next messages don’t have knowledges, consequently the fb endpoint stays busy. The function usbd_edpt_busy returns true and no other message are sent.
Even if I use the sample uac2_speaker_fb using the AUDIO_FEEDBACK_FIFO_COUNT method
I patched the function audiod_fb_fifo_count_update to print an “Ok” when the message is sent, and I get only one “Ok” at the beginning of the playback
How the feedback could work in these conditions, where am I wrong ?

// Schedule a transmit with the new value if EP is not busy - this triggers repetitive scheduling of the feedback value
if (!usbd_edpt_busy(audio->rhport, audio->ep_fb))
{
printf("ok\n");
audiod_fb_send(audio);
}
Else
{
printf("ko\n");

}

Thanks

[HiFiPhile]

Hi,

I assume that every period of time, we send a feedback message to the host

Exactly, you issue sounds strange, seems like the host didn't send IN token for feedback packet.

Did you test with Windows, could you try to uninstall the device driver in Device Manager and try it again ?

Do you have a USB protocol analyzer to see what happened ?

[Lurcy38]

Hello hifiphil,
Thanks for the support
I have 2 pcs under windows 10. Both reports same issues.
I will log the traffic using using wireshark and will share the result
I have uninstalled / reinstalled usb driver but same result…
I took your latest branch rx_fb and build the uac2_speaker_fb, I add the support for the stm32h735g-disco ( only board.h) and add the following code in audiod_fb_fifo_count_update() and the result are always the same, whatever the feedback method, the EP stays busy after the first message.
The strange things are a series of ASSERT at the beginning, but the USB device is recognized by windows and accepts to play a wave using audacity
usbd_edpt_xfer 1243: ASSERT FAILED
usbd_control_xfer_cb 218: ASSERT FAILED
…

Patch on the audio class:

// Schedule a transmit with the new value if EP is not busy - this triggers repetitive scheduling of the feedback value
static int cpt;

if (!usbd_edpt_busy(audio->rhport, audio->ep_fb))
{
printf("Ok %d:%d\n",cpt,clock());
audiod_fb_send(audio);
}
else
{
printf("-Ko-- %d:%d\n",cpt,clock());
}
cpt++;
}

Log result Result :

Speaker running
usbd_edpt_xfer 1243: ASSERT FAILED
usbd_control_xfer_cb 218: ASSERT FAILED
Get channel 0 volume range (-50, 0, 1) dB
Get channel 1 volume range (-50, 0, 1) dB
Get channel 2 volume range (-50, 0, 1) dB
Clock get 4 freq ranges
Range 0 (44100, 44100, 0)
Range 1 (48000, 48000, 0)
Range 2 (88200, 88200, 0)
Range 3 (96000, 96000, 0)
Get channel 1 volume 0 dB
Get channel 1 mute 0
Get channel 1 volume 0 dB
Get channel 1 mute 0
Get channel 1 volume 0 dB
Get channel 1 mute 0
Get channel 1 volume 0 dB
Get channel 1 mute 0
Get channel 1 volume 0 dB
Get channel 1 mute 0
Get channel 1 volume 0 dB
Get channel 1 mute 0
Get channel 1 volume 0 dB
Get channel 1 mute 0
Clock set current freq: 48000
Get channel 1 volume 0 dB
Get channel 1 mute 0
Get channel 1 volume 0 dB
Get channel 1 mute 0
Clock set current freq: 48000
Ok 0:92831
-Ko-- 1:92836
-Ko-- 2:92841
-Ko-- 3:92846
-Ko-- 4:92852
-Ko-- 5:92858
-Ko-- 6:92863
-Ko-- 7:92869
-Ko-- 8:92874
-Ko-- 9:92880
-Ko-- 10:92886
-Ko-- 11:92892
-Ko-- 12:92897
-Ko-- 13:92902
-Ko-- 14:92906
-Ko-- 15:92911
-Ko-- 16:92917
-Ko-- 17:92922
-Ko-- 18:92927
-Ko-- 19:92933
-Ko-- 20:92939
-Ko-- 21:92943
-Ko-- 22:92948
-Ko-- 23:92953
-Ko-- 24:92958
-Ko-- 25:92964
-Ko-- 26:92969
-Ko-- 27:92973
-Ko-- 28:92978
-Ko-- 29:92982
-Ko-- 30:92987
-Ko-- 31:92992
-Ko-- 32:92997
-Ko-- 33:93001

[HiFiPhile]

It's not normal to have these ASSERT FAILED, maybe something is wrong in h5 & h7 porting. Could you put the project on GitHub ?

[HiFiPhile]

Could you set CFG_TUSB_DEBUG=3 for the assert failed issue ?

For H7, does apply #2333 make any difference ?

Btw, what if compile with LOGGER=rtt to use SEGGER RTT for logging since UART is time consuming ?

[Lurcy38]

Hello hifiphil,
Here are 2 log files

https://filebin.net/24walb6s12uck35k

pushReset9x.log is a log with 9 resets. It seems that enabling traces causes more asserts.
puhsReset+Stream a wav.log is another flog with a reset + a streaming from audacity using FB. I just added in audiod_fb_fifo_count_update() a trace when a message is sent on the FB endpoint. (at the line 2820 ---- audiod_fb_send(audio) --), this trace is shown only once.
These log hasb been done on H7 and speaker_fb
Thanks again :)

[Lurcy38]

no dwc2-add-endpoint-allocation-support and Flush-FIFO-on-bus-reset doesn't make a diffrence

[HiFiPhile]

I've resolved the assert issue in last commit, it was due to HID debug interface start transfer before stack init 🤣

From your log the feedback is working, both IN and OUT transfer are completing, data size is also regulating between 188 and 192 bytes:

  AUDIO xfer callback
  Queue ISO EP 01 with 388 bytes ... OK
USBD Xfer Complete on EP 01 with 188 bytes
  AUDIO xfer callback
  Queue ISO EP 01 with 388 bytes ... OK
USBD Xfer Complete on EP 81 with 4 bytes
  AUDIO xfer callback
  Queue EP 81 with 4 bytes ...
USBD Xfer Complete on EP 01 with 192 bytes
  AUDIO xfer callback
  Queue ISO EP 01 with 388 bytes ... OK
USBD Xfer Complete on EP 81 with 4 bytes

Maybe due to UART print timing HID transfer is not working while streaming, otherwise you will see log of all 3 EPs:

AUDIO xfer callback
  Queue EP 81 with 4 bytes ...
USBD Xfer Complete on EP 01 with 192 bytes
  AUDIO xfer callback
  Queue ISO EP 01 with 388 bytes ... OK
USBD Xfer Complete on EP 82 with 20 bytes
  HID xfer callback
  Queue EP 82 with 20 bytes ...
USBD Xfer Complete on EP 81 with 4 bytes

What does the script audio_debug.py show about FIFO level ? Please use RTT or disable log for streaming test.

[HiFiPhile]

For your initial question I patched the function audiod_fb_fifo_count_update to print an “Ok” when the message is sent, and I get only one “Ok” at the beginning of the playback, sorry I haven't touched the code awhile and I gave you false information which should be:

• As the comment says, it only schedule the 1st feedback packet, that's why you only got 1 “Ok”.
  

  tinyusb/src/class/audio/audio_device.c

  Lines 2296 to 2300 in fc71050

  	// Schedule a transmit with the new value if EP is not busy - this triggers repetitive scheduling of the feedback value
  	if (!usbd_edpt_busy(audio->rhport, audio->ep_fb))
  	{
  	audiod_fb_send(audio);
  	}

• Following feedback packets are sent inside transfer complete callback audiod_xfer_cb()
  

  tinyusb/src/class/audio/audio_device.c

  Lines 2221 to 2226 in fc71050

  	// Schedule a transmit with the new value if EP is not busy
  	if (!usbd_edpt_busy(rhport, audio->ep_fb))
  	{
  	// Schedule next transmission - value is changed bytud_audio_n_fb_set() in the meantime or the old value gets sent
  	return audiod_fb_send(audio);
  	}

[Lurcy38]

Many Many thanks hifiphile,
Asserts are non longer present thanks to your last patch, and I understood that FB messages could be is sent from several places in the code.
tud_audio_n_fb_set();
audiod_xfer_cb();
audiod_fb_fifo_count_update(),
….
I'm stupid, not having checked this before :). As usual, the issue is often between the chair and the keyboard :).

[HiFiPhile]

@Lurcy38 Is audio feedback work correctly now ? I'll try to get the PR merged :)

[Lurcy38]

I HifiPhile,

yes, perfectly on stm32H5 and stm32H7.
strangely, i still have pops (every ~15 secs) when the frequency is very low ~8000HZ
it is not an issue with tinyusb audio, but probably the host feedback algo that seems to converge too slowly when I send the monitoring, and the latency buffer becomes underrun. Only for low frequency. ???. I need to tune my parameters for this specific frequency.
I any case, a big thanks for your support :)