Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Request]: robust DAW support (yabridge and wineASIO) #1227

Open
titote84 opened this issue Mar 22, 2022 · 10 comments
Open

[Request]: robust DAW support (yabridge and wineASIO) #1227

titote84 opened this issue Mar 22, 2022 · 10 comments
Assignees
Labels
Feature request Requires evaluation a feature that requires further evaluation to be accepted or rejected

Comments

@titote84
Copy link

Tell us the problem or your need

for some sound editors or DAWs wineASIO and yabridge support is very important.
At the moment, using yabridge in native wine with the VSTs installed in bottles works very well. It would be amazing to have yabridge included in bottles with setting options like yabridget (GeekosDAW) or the settings panel in AV Linux MX Edition.

https://github.com/robbert-vdh/yabridge

wineAsio on the other hand is necessary for some low latency audio input in software. Installing it is complicated. having a switch like latencyflex would be perfect.

https://github.com/wineasio/wineasio

Describe the solution you'd like

have a switch like latencyflex or dxvk for wineASIO and the inclusion of yabridge (yabridgectl) with settings options.

Other solutions?

Additional context and references

@mirkobrombin mirkobrombin added the Requires evaluation a feature that requires further evaluation to be accepted or rejected label Mar 22, 2022
@mirkobrombin
Copy link
Member

Thanks for reporting

@mirkobrombin mirkobrombin added this to the 2022.4.14 milestone Mar 28, 2022
@mirkobrombin mirkobrombin removed this from the 2022.4.14 milestone Apr 7, 2022
@derkrasseleo
Copy link

Would also love to see WineASIO support, as Ableton is unusable without it.

@eCompassion
Copy link

I'll keep an eye out for this too, as a user of Ableton, DAWs and VSTs on Linux and having bottles manage the environment would streamline my process.

@Ishan333
Copy link

I've tried installing WineASIO in a bottle for Live, no success right now. Adding both WineASIO and yabridge support would be great.

@eCompassion
Copy link

WineASIO is particular about which version of WINE is in use 8.2 Staging was the last before some breaking changes.

@JAKAMI99
Copy link

JAKAMI99 commented Nov 9, 2023

Also searching for a newbie way to get low latency working in my DAW (FL Studio)
I have no luck with JACK Audio and Wineasio.
Really complicated, would love full support with bottles.
Just checking a dependencie "wineasio" in the settings together with some instructions, how to configure the JACK Audio Server would be lovely

@derkrasseleo
Copy link

Also searching for a newbie way to get low latency working in my DAW (FL Studio) I have no luck with JACK Audio and Wineasio. Really complicated, would love full support with bottles. Just checking a dependencie "wineasio" in the settings together with some instructions, how to configure the JACK Audio Server would be lovely

That's exactly what I'm searching for as well.

@ejaa3
Copy link

ejaa3 commented Nov 11, 2023

With the little I experienced, I think the correct direction is this:

WineASIO is something Bottles should implement (read its README.md), but:

  • I'm not sure JACK works with Flatpak, but pipewire-jack does, and for this it seems necessary that Bottles be able to read and write the xdg-run/pipewire-0 path.

  • It has a small GUI in PyQt.
    I guess it should be rewritten in GTK to avoid relying on Qt.

I don't know if WineASIO really decreases latency with PipeWire. I think this really depends on your PipeWire setup. For my part I use pipewire-pulse with the default Arch Linux configuration, except for one thing: I use 44100 instead of 48000 as the sample rate, BUT WineASIO would allow customizing the number of audio inputs and outputs for a DAW running with Wine if necessary (should be noted in the PatchBay of QjackCtl, qpwgraph or Helvum), and this is valuable.

As for yabridge, I just tested it with REAPER in the Bottles sandbox and it worked without problems, but I'm not sure Bottles should implement it. I will leave instructions of what I did so that a decision can be made:

  1. Give Bottles read and write permission to the following paths:
    xdg-run/pipewire-0 (for REAPER), ~/.vst, ~/.vst3 and ~/.clap. With Flatseal it's easier.

  2. You must create the last three if they do not exist (flatpak does not do it automatically for me).
    If they already existed, perhaps you should rename them (a fallback) to test with empty paths.

  3. Use Bottles, create a test bottle and install plugins (here are several).
    Remember the path where you installed them. For example, for VST3 plugins it should be:
    /path/to/my_bottles/test_bottle/drive_c/Program Files/Common Files/VST3

  4. Give Bottles the following environment variable so that yabridge runs wine with the correct prefix:
    WINEPREFIX=/path/to/my_bottles/test_bottle (I also used Flatseal)

    I don't know if it's correct to have that variable set when running Bottles, so I'll give an alternative in step 6.

  5. Prevent yabridge from running a wine that is not the selected runner for that bottle.
    Otherwise the bottle would be reconfigured for that wine, instead of respecting the Bottles configuration.

    Maybe you should open Bottles and check out the runner. For example, for soda-7.0-9 you would set something like:
    WINELOADER=/home/username/.var/app/com.usebottles.bottles/data/bottles/runners/soda-7.0-9/bin/wine

    I think here you can't reduce /home/username to ~ or $HOME (I don't know about xdg-home).

  6. At this point you will run executables inside the Bottles sandbox like this:
    flatpak run --command=sh com.usebottles.bottles -c /path/to/executable

    If you don't want to set the variables from steps 4 and 5 for Bottles itself,
    you could (or should) also set them in the command above like this:
    flatpak run --command=sh com.usebottles.bottles -c 'WINEPREFIX=... WINELOADER=... /path/to/executable'
    (note the single quotes)

  7. Download REAPER and extract it somewhere with read (and write?) access to Bottles.
    For example in: ~/.var/app/com.usebottles.bottles

  8. Test REAPER with the following command, then close it:
    flatpak run --command=sh com.usebottles.bottles -c /path/to/reaper

  9. Follow the usage in the README.md of yabridge, but:

    • Do not extract yabridge to ~/.local/share, but to ~/.var/app/com.usebottles.bottles/data
    • You should run yabridgectl like this, for example, with the status argument:
      flatpak run --command=sh com.usebottles.bottles -c '~/.var/app/com.usebottles.bottles/data/yabridge/yabridgectl status'
  10. Reopen REAPER and it should recognize the plugins. Insert a new track (or effect on a new track) and open one.

The downside is that you would have to use a portable Linux DAW in the Bottles sandbox. Additionally, a Linux DAW would support Linux plugins, so Bottles would have to "extend" LinuxAudio for a DAW running in the Bottles sandbox to recognize plugins installed with flatpak.

For me, the maximum support that Bottles could give to yabridge would be not to support it, but to give it meaning, that is, for Bottles to "extend" LinuxAudio even though Bottles itself is not extendable with audio plugins. This way a DAW can use Linux plugins as well as Windows plugins with a Bottles runner under the restrictions of flatpak. I still think this is wrong, although I think it costs nothing.

But I do believe that DAWs installable with flatpak should optionally depend (or extend, or support) on Wine (if that is possible in flatpak). I suppose the DAW could be guided by Bottles' manifesto. In both cases I think the musician should be responsible for installing yabridge, whether in a DAW or Bottles sandbox.

There is an issue in yabridge about it.

@deusnovus
Copy link

I don't know if WineASIO really decreases latency with PipeWire. I think this really depends on your PipeWire setup. For my part I use pipewire-pulse with the default Arch Linux configuration, except for one thing: I use 44100 instead of 48000 as the sample rate, BUT WineASIO would allow customizing the number of audio inputs and outputs for a DAW running with Wine if necessary (should be noted in the PatchBay of QjackCtl, qpwgraph or Helvum), and this is valuable.

I played with pipewire-wineasio last week and low latency performance was great. I also routed all my audio through qpwgraph (since Helvum still can't store permanent connections). However, what really plagues Ableton Live on Linux is the high CPU temps / inefficient Wine performance on both idle and busy, and depending on what Wine build you're using, the M4L UI glitches and the "Failed to open audio device" bug due to a later Wine regression.

There is work being done to fix that with patches, but I don't know if the Bottles dev team can do anything about it. Having per-app-based custom Wine builds packaged via Bottles would be far safer than installing them yourself, for sure. I'm not sure about the overall state of Ableton Live in Linux, but companion flatpak DAWs in Flathub would be amazing...

@AndreCox
Copy link

Hello I was wondering if there is any update on this issue as I'm trying to run ableton live 11 right now and it's completly unusable without low latency audio

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature request Requires evaluation a feature that requires further evaluation to be accepted or rejected
Projects
No open projects
Status: Todo 🎈
Development

No branches or pull requests

9 participants