Investigated this and it turned out to be an amusing bug: audio decoding was happening three times instead of just once lol. I've put up a PR to remove the wasteful redundant decoding:

https://github.com/FluidInference/FluidAudio/pull/799

With the updated PR code, ran a test comparing transcribing (using Parakeet V3) a 1 hr stereo 44.1 kHz mp3 vs the same audio in 16 kHz mono wav format. The result was about 21.3% slower with the mp3 vs the wav, i.e. that's the overhead of decoding + resampling.

Currently the decoding + resampling is done up front. If it was done in a pipelined fashion with the inference, that overhead can be eliminated. This is what I did in a recent app I made:

https://apps.apple.com/us/app/drea-podcast-ad-blocker/id6759...

It uses FluidAudio as well, but I forked it and replaced the audio decoding code to (a) use mpg123 instead of the native Apple API and (b) do audio decoding and inference in a pipelined fashion. These two changes effectively eliminated the overhead. mpg123 is quite a bit faster than the native Apple API at mp3 decoding (has some very optimized arm64 assembly routines), and the pipelining ensures that the inference is never starved by the mp3 decoding.

Contributing this pipelined setup to FluidAudio would be good.