Hello @Jud and thank you again for the your generous contribution.
About your questions, I’d say that generally speaking docker imposes a very small overhead if you compare the performances against natively installed applications. Such overhead is negligible with modern hardware (even a Pi4 is more than capable). You pay the most in terms of download/build time (for downloading or rebuilding the images), but about download, when using regular installations, you would still have to download updated binaries when a new version comes out.
So why bother?
- you can use virtually any distribution, the only prerequisite is to have Docker installed.
- you don’t actually have to “install” anything on your system, so we are done with libraries/binaries incompatibilities (but with this, I am not saying that Audirvana is problematic under that aspect: for what I have seen it isn’t problematic at all).
- Stop/remove the container and it’s just it was never there. No packages to remove. Maybe just the images if you never want to use that again.
These are some of the general advantages of Docker as a containerization platform, not anything specific to Audirvana or any audio-related application.
Container startup time can be marginally longer (again, I consider it negligible on modern hardware).
In terms of audio quality, I cannot notice any difference if I try to compare the sound quality with what comes from a natively installed equivalent application. I’d be surprised if anyone was proven to be able to tell one from the other reliably, so in a proper A/B blind test.
So I am currently using docker on most of my devices for audio, with great satisfaction. For example with apps like mpd/upmpdcli, squeezelite and others, it’s so easy to create multiple instances of any of those, maybe if you have multiple dacs or if you want to test different configurations (e.g. with upsampling or not). Try with regular packages: you will find yourself creating new systemd units or scripts. And what if you want different versions of the same app? a nightmare without containerization (although it’s possible of course).
Moreover, in the case of Audirvana core, if one should want to install the docker image on a server device, with no audio devices attached, as a source for remote players, you wouldn’t even have to worry of docker passing audio devices to the container correctly (my opinion: it does pass audio devices correctly, so we should not worry) because this would “just” be a server without any audio capabilities by itself alone.
Different considerations can be made about Windows and MacOS machines. Those o.s. generally run docker containers using Docker Desktop, which in turn operates through a hidden virtual machine. The containers run on that virtual machine. In this scenario, I’d rather not run audirvana with docker for at least these reasons:
- audio devices pass through a virtual machine (never tried that, but I don’t like the idea too much).
- at least with windows, host networking does not work afaik, so your remote app would not “see” the server.
- this might be the first reason, but anyway: there is a desktop version of audirvana avaiable, so I would not bother
About the external usb drive, on a linux system (so where I consider using docker makes sense).
You need to make sure that the drive is mounted when you start the container. If your use case includes connecting the drive after startup (very likely to happen if you use a laptop I’d say), you would need to start the container after that event. A tool like Portainer might help you reduce the need to resort to the command line if this is something you don’t like to do. Also, usb dac might be unavailable if connected after the container is started. Again, nothing that a container restart would not solve.
I hope this is helpful. Looking forward to hearing your comments. Thank you again!
