[Request] MP3 support in the packages

[easyjoh]

Hi,

I notice the frontends support audio_decode and mp3_encode.

Would it be possible to provide an docker image with these two frontends enabled? For me it is on the CUDA driver (arm), dgx spark that is.

Thank you for the great work.

[0xShug0]

@easyjoh Thanks for your kind words! And yes, a separate Docker image/release is the plan (#541 (comment)). I just need some time to figure this out.

[easyjoh]

Sounds good. Thank you.

[0xShug0]

@easyjoh Let me know if this works https://github.com/0xShug0/audio.cpp-server-frontends/pkgs/container/audio.cpp-server-frontends

[Tech-no-1]

Hi, could we please get a Vulkan/CPU version as well? Not everyone has got an overpriced Nvidia GPU/system 😅. I can offer testing it again.

[0xShug0]

Sure!

[0xShug0]

Please check the latest release of the frontend repo.

[Tech-no-1]

Okay, so here's an overview of what I tested, including the corresponding result:

• CPU & Vulkan backends/images -> both functional ✅
• Frontend modules: audio_decode, mp3_encode and websocket -> all functional ✅
• Open WebUI STT (transcription) & TTS via http/ws inside an internal docker network -> all functional ✅
• Docker healthcheck via the /health endpoint -> fails because curl is missing, the endpoint is accessible from another container though and returns the expected status
• Not tested: HTTPS module (because isolated/internal only)

Some annotations and thoughts:

• Open WebUI slim images do not include the necessary transcoding components, therefore transcoding to MP3 is not possible before the file is sent to audio.cpp, resulting in a 400 bad request (because Open WebUI is sending webm).
• You need to mount //.cache to a volume, if you want the Vulkan (Mesa) shader cache to be persistent. Additionally, if you run the container as non root, you get a warning that you do not have the permissions to access //.cache and that it is/gets deactivated. This could be included in the README.
• I don't know if this already exists, but it would be great to have a ttl (time to live) variable. Globally or, preferably, for each model. Currently, the models remain permanently loaded in RAM/VRAM, which is good for fast responses, but not so much for efficient resource management (on a server). They can occupy several GB that could be used by or are needed for other tasks. It would be beneficial to unload them after a certain idle period in order to free up resources.
• A somewhat more sophisticated access management would also be nice 😅, that is a more specific cors_origins and preferably API key authentication.