I wish I could help in a more direct and specific way. I have used Qt on imx8, but I did not do anything with audio, nor with docker. (The docker part of your situation is "probably" irrelevant but it was wise of you to mention it. Maybe someone else will point out that docker is indeed relevant.)
All I can do now is make some generic observations. Things I would probably experiment with if I were in this situation.
(stating the possibly-obvious) the "underrun" message would seem to indicate that something in your code or the QAudio code is not filling the pcm buffer as quickly as it should. It is very encouraging that aplay produces the sound correctly.First thought:
Because of those 2 observations, and also because you already made (what I would call) "special accommodations" by forgoing QSound and QMediaPlayer due to platform limitations... (in other words, you are making code that is in some ways "tied to" or "hamstrung by" your platform already)
perhaps you would entertain just using libasound (<alsa/asoundlib.h>) directly? It could be an instructive exercise even if you ultimately are able to then switch back to using QAudio.
You could look at the source code of aplay to see what it does (since it successfully plays your sound clips): https://github.com/bear24rw/alsa-utils/blob/master/aplay/aplay.c
Second thought:
Look for ways to configure the buffer size. If your sound clips are small enough, and if the PCM and/or sound layers and hardware support it, maybe you can preload the audio into one big buffer before playing it. This might involve buffer flags in QAudio and/or buffer settings in the linux system somewhere.
Third thought:
Is there anything you can do to improve the overall performance of your application so it could "keep up" with its buffer-filling duties? Are there too many competing threads when audio is trying to play? Is an important audio-related thread blocked that shouldn't be?
It could also be as simple as compiling a fully optimized build, if you are not yet doing that. If your app binary is currently unoptimized (i.e. compiled with -O0), then simply adding optimization flags at compile time might help.