USB_Audio -> I2S DAC Corrupted packet on buffer roll back

[PCamp.2]

I am using STMCubeIDE latest and an F411CE.

I used the MX wizard to enable USB_Audio class device set to 48000 s/s

I configured an I2S with master clock on IS2.

It plays whether I start the circular DMA in the AUDIO_Init function or in the AUDIO_CMD_START case within AUDIO_AudioCmd_FS().

However there is a corrupt packet at the end or start of the buffer.

I looked into the USB_AudioSync() method and seen it is expanding or contracting the buffer by 4 bytes. I have tried to use it, disabling circular mode and using the DMA complete call back to call USB_AUDIO_Sync() which then restarts the stream with the different size buffer.

STILL there is a corrupted packet in the buffer.

What am I missing?

I could consider it plausible that the audio sync is trying to shorten the buffer but for some reason my DMA goes straight on past it. But I am currently relaunching the non-circular I2s DMA transfer with the size that AudioSync sent me.

Also... those USB_DEVICE libraries are not easy to deal with, Eclipse disowns them and will not resolve references in them, it seems all structs as Anon type for example.

The documentation is where? The st.wiki.com has a list of function and nothing about how to use them. Older F0xx guides are out of date.

I can find exceedingly long technical papers teaching me ALL about how fancy the USB LL and stuff is and how USB works in extraordinary detail, but nowhere can I find a "User guide" to the librarys.

The example linked to here in other threads is for a very specific STM32 Discovery board which includes a codec and most of the actual code is specific and bespoke to that device. That is NOT a reference implementation for the library. It's full of BSP macros. You will only have that BSP if you bought that specific discover board.

[PCamp.2]

If you removed all the magic numbers. (assign them to constants)

Stop using abreviations and contractions for variable/function names...

the rest of it would read like english.

case OP_CODE_1169_USERREQ1: ES9038_Set_OutOfPhase()

That is almost english. "In the case of OP CODE 1169 aka USER REQ1 set the DAC out of phase"

If you see a random number in the code your brain reads straight past it.

I mean, what are Taste: 17. 17 is meaningless. Give it a name!

I routinely reject pull requests with even contain a SINGLE magic number or a magic NULL in a parameter line. I will even require people do to this:

aParam=null;

aFunctionCall( with, a, aParam );

// instead of

aFunctionCall( with, a, null );

Other wise you have to go and look up what that parameter is. The same applied for magic numbers like aFunctionCall( 5, 6, 7, 8 ); Don't do this if you can avoid it. Assign them to variables, pass the variables, let the compiler do its optimisation. Etc. etc.

Here's a very quick and dirty example of my code. Granted it's Arduino FW.

Even I have magic numbers in here, but I was also just about to fix it. Even making constants for the 0xF bit mask to explain it as "LAST_4_BITS" insetad of a random 0xf. Replacing the 1 and 2 with BIT_1 and BIT_2 might be a little extreme, but no harm.

https://i.imgur.com/hvsUOCs.png

(rotary encoder state machine)