AUDIO examples fail for me, while CDC and MIDI work #1899
Replies: 13 comments
-
|
after further investigation I think this is related to the fact that the Nucleo onboard OTG port is only capable of USB FS, wheres USB AUDIO 2.0 requires HS, if I'm not mistaken |
Beta Was this translation helpful? Give feedback.
-
It's not case. Could you try #1825 ? |
Beta Was this translation helpful? Give feedback.
-
|
I tried it, but unfortunately, this does not fix my issue |
Beta Was this translation helpful? Give feedback.
-
|
Please enable debug logging in tusb_config.h and upload log. You can also try F412 BSP in https://github.com/hathach/tinyusb/tree/master/hw/bsp/stm32f4/boards/stm32f412nucleo |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for coming back to me! I set debug level to 3 and hooked up tu_printf to an UART. Here's what I got when plugging the device in: |
Beta Was this translation helpful? Give feedback.
-
|
Please use unmodified example, your are missing tud_audio_get_req_entity_cb() in example's main.c tinyusb/examples/device/audio_test/src/main.c Line 272 in 86c416d |
Beta Was this translation helpful? Give feedback.
-
|
oh sorry for the confusion... I forgot to re-enable the resp. source file. But that is not the issue, it does not work either way. I updated the log above to what's being reported when |
Beta Was this translation helpful? Give feedback.
-
|
I tried the UAC2 headset example and this seems to work (at least partly). I got two runtime assertions in dcd_synopsis.c;
but I can stream audio to the device and record it back :-) The recorded audio is a bit corrupted, which I'll investigate now. But still this is a huge step forward for me |
Beta Was this translation helpful? Give feedback.
-
|
In fact I get loads of assertions with the headset example... I took a chance and commented some of them out just to see if it works in principle; however, finally I got this: in usbd.c, which of course cannot be skipped... |
Beta Was this translation helpful? Give feedback.
-
|
No you touch asserts they exists for a reason ! You said you excluded dcd_synopsis.c (which is good to use dwc2.c) how did you hit assert inside it? |
Beta Was this translation helpful? Give feedback.
-
|
there are two synopsis folders, one And, I would never leave the assertions commented out, I just wanted to see if it works at all. I know they're there for a reason :-) What else I can I try? |
Beta Was this translation helpful? Give feedback.
-
|
moved to discussion, since it is not clear that this is a bug from stack or user issue. Please use un-modified examples with makefile (cube integration can introduce bug), based on one of the supported boards. |
Beta Was this translation helpful? Give feedback.
-
|
Hi guys, first of all, thanks for helping, I appreciate that a lot! I created a new project, which is a most vanilla representation of the headset example. I used the best fitting BSP file (f412 nucleo), used the stm32f4 hal driver included in tinyusb and tried to keep everything as is in the example. Still, I get the same behaviour. When recording the headset input in Logic on my Mac, I get distorted audio (hard signal jumps with a suspicious distance of 480 frames). And, I get the same assertions when plugging the device into a mobile phone (which is the use case I'm after). For example on iOS, I get the default switch branch in And, when plugging into an Android phone, all the other assertions come. It does not feel like it's related my project structure. Can you check the headset example on a mobile device? |
Beta Was this translation helpful? Give feedback.
-
Operating System
MacOS
Board
Nucleo F413ZH
Firmware
examples/audio_test
What happened ?
I added tinyusb to my CubeIDE project (which worked mostly flawlessly). Then I tried some of the examples. Both audio examples refused to work, while cdc_dual_ports and midi_test worked without any problems. I have another project, where I use STM's default USB middleware and there I can implement a working USB audio device; I also copied over the clock settings from this project in order to make sure they work. It may not be 1:1 comparable, since the audio_test example is a microphone, whereas my STM project defines a speaker.
When plugging into Windows, device manager recognizes the device, but complains that it cannot be started.
How to reproduce ?
CFG_TUSB_MCU=OPT_MCU_STM32F4tusb_init()and hook uptud_int_handler()Debug Log as txt file
If I plug the device into Linux, dmesg gives me the following errors:
Screenshots
No response
I have checked existing issues, dicussion and documentation
Beta Was this translation helpful? Give feedback.
All reactions