search

89luca89 / distrobox

Use any linux distribution inside your terminal. Enable both backward and forward compatibility with software and freedom to use whatever distribution you’re more comfortable with. Mirror available at: https://gitlab.com/89luca89/distrobox
https://distrobox.it/
GNU General Public License v3.0
9.93k stars 410 forks source link

[Discussion] How to connect container audio to host pipewire + expose Audio Plugin Paths #310

Closed revast closed 2 years ago

revast commented 2 years ago

Is your feature request related to a problem? Please describe. The Discussion is about the ablity to use Audio in Containers together with the new Pipewire Audio Framework. Specifically, what is needed to be done for having it working great within the Scope of Pro Audio. Hence one part is also about Audio Plugin PATHs, but there is propably more to consider, like the awareness of containerized Audio Applications of low-latency and realtime prio settings for example)

  1. It seems like podman could expose a Pipewire socket on Host (/run/user/<id>/pipewire-0)? It is stated that Flatpack does it like this already. See This Issue @Pipewire gitlab Ideally, this just works, and all containerzed Audio Applications that can speak to Pipewire can also do this to the one on the Host and can use it happily (practically all Applications which use one of ALSA, PulseAudio and JACK).

  2. For running Audio Plugins from a container, I suspect that setting the appropriate PATHs should be enough. I can be wrong though... So setting the right paths should have containerized plugins show up on host and vice versa.

Describe the solution you'd like

  1. If you have detected Pipewire as Audio System on the Host, Audio-Applications in the Container should use the Host's Pipewire, and they should be useable in the same way as Audio-Applications on the Host, e.g. show up in pw-top, operate in the same constraints. For example, for Pro-Audio LowLatency applications, do not introduce more Latency, respect the RTPRIO settings of the Host; Basically everything RealtimeConfigQuickScan is recommending)

  2. It would also be important to have the common Audio Plugin PATHs for LV2, LADSPA and VST Plugins set - so that Audio-Applications in the Container can also see the Plugins installed in the Host (and preferably as well the ones in other Containers), as well as Audio-Applications in the Host can see the Plugins in the Containers.

These would be the default paths for Audio Plugins (where VST does not really have a common standard in Linux):

export LADSPA_PATH=/usr/lib/ladspa:/usr/local/lib/ladspa:~/.ladspa
export LV2_PATH=/usr/lib/lv2:/usr/local/lib/lv2:~/.lv2
export LXVST_PATH=/usr/lib/lxvst:/usr/local/lib/lxvst:~/.lxvst:/usr/lib/vst:/usr/local/lib/vst:~/.vst

Sadly, the default paths are not always used by all distributions (see https://manual.ardour.org/appendix/files-and-directories/) , but as there are not so many maintained pro-audio related repositories out there, it would be a good start to have support for these, which are Debian- Arch-, OpenSuse- and Fedora-based.

Slightly Offtopic: As there is now very good support for using Windows-Based VST Plugins in Linux via Wine and Yabridge - having this containerized would be a nice thing - many people are struggling with the setup and as there is not the same Wine Version on every Distribution, the results of running this can be different from installation to installation... this would then have additional PATHS to consider though (like typically ~/.wine/drive_c/Program Files/Common Files/VST2/, which would be nice to add as well - thats for sure a project of itself, but adding these paths already to the VST Plugin's LXVST_PATH would be nice.

Describe alternatives you've considered This may be very wide spread alternatives, but, nevertheless, are thinkable...

  1. There is also the consideration to use Flatpack for all of this, as which would also work fine in the context of Pipewire, but as these applications are then sandboxed, the host cannot see the flatpacked plugins...

  2. There is also Audiogridder which allows to transfer audio,midi plus the GUI of audio plugins over the network (using ffmpeg), this also works cross-platform. But only for audio plugins (VST, AU for now..). This allows to offload CPU intensive Audio Plugins to another Host, and just display it's graphics, hear audio and have midi in your DAW. Also has the advantage to be able to pin certain Plugins to a specific CPU core, when being run on the same machine... but Server functionality for Linux is not yet implemented.

Additional context Just want to add the fact that many Distributions start switching to Pipewire, so having an eye on this in the context of Distrobox would be cool. Bear in mind that Pipewire is not only about audio, but "piping" video as well (somewhat similar to Syphon on MacOS). Deeper Interoperation between the Containers and Hosts in terms of sharing Pro Audio related Settings would definitely boost the versatility of Distrobox.

89luca89 commented 2 years ago

I must admit most of this is way over my head :sweat_smile:

Right now Host's pipewire is already exposed inside the container:

image

Is this not the case for you?

89luca89 commented 2 years ago

@revast any news on this?