AnsweredAssumed Answered

STM32L4 Discovery CubeMX USB Host Audio callbacks

Question asked by Aussie Susan on May 2, 2016
I am using the latest STM32CubeMX (V4.14) and the latest version for the STM32L4 family (version number escapes me right now) and I am trying to understand how to properly use the Discovery board to act as a USB Audio host (for sending audio to some headphones).
The headphones are detected and enumerated correctly and I can see in the "USB Host Library (UM1720) document about the callback values that the USB generic host layer provides and the calls I need to make to the Audio layer to get things going.
(Minor point: Is Rev 3 the latest version of UM1720? I makes reference to only some of the callback enumerations and also talks about changes that should occur in V3 to do with SOF callbacks but the generated code does not seem to use that approach. Also when I try to make calls to the audio class layer in the HOST_USER_CLASS_ACTIVE state, I get errors that the driver is not yet set up! It really helps to have accurate and up-to-date documentation when you are trying to learn.)
My confusion comes in deciding where to put my calls for the Audio class layer. In 'main' in the driving loop there is a call to 'MX_USB_HOST_Process()' which takes no parameters. In 'usb_host.c" there are the declarations for the USB host handle which the above mentioned function passes to the 'USBH_Process' function.
This wold appear to be the correct place to put in my code to check the current state of the Audio class (set frequency and volume, start the iscohronous transfers and monitor them for the buffer being consumed) but there are no places in the function for user written code. If I put code in that function, it gets overwritten if I regenerate the project.
So, where should I put my code that will be executed on a regular basis where I can also get access to the USB Host handle?
As a suggestion, I would think it better if there were callback functions added for the Audio class driver for when the buffer is about to be exhausted rather than having to  make repeated calls to USBH_AUDIO_GetOutOffset.