Hey Stefan,
We're generally interested in fixing these kinds of regressions, and also
performance regressions. Did you file bugs for them? (I see your comment
on
46056; sounds complicated indeed)
Generally, because I use heavily modified code / fork-of-wine I do not file bug reports, unless I can reproduce them on vanilla wine (or Staging). Occasionally, I will reach out to the author of a particular related patchset, or something like that -- but I don't want to be spamming/filing invalid bug reports. ( I know the rules ).
Yup, using Wine to run heavily multithreaded proaudio software is a pain / complicated to do... People have tried to fix it all via Winelib apps / bridging - but fundamentally, that's not the (full/proper) solution. Wine itself needs to be patched / fixed, because even with bridges, you will eventually hit a wall due to limitations in Wine.
I'm sure you remember the Muse Receptor folks? (Wine 1.x era) and the kinds of hacks they used to employ? (unix pipe synchronization per app, setting realtime from without wineserver, RT hacks in kernel32, specifically compiled libs/windows dlls, etc)... or the Wine-RT patch that lives in Staging? it seems every few years, new ideas/implementations/code rolls out that helps improve the situation... but much of it never makes it upstream (often for very valid reasons. eg: too platform-specific. too hackish. etc).
Lots of handy patchwork floating around these days; stuff in Proton.. Zeb's Esync/Fsync code.. Lots of Remi Bernon's work (LFH, keyed_events+futexes, and so on).. Some of Torge Matthies' patchwork; especially that killer multithreaded wineserver patchwork (shmem per thread for requests/replies)... but I still needed further hacks on his code; dropping his spinning code (it stalls apps like NI Kontakt), AND I had to set up these threads' pthread attributes for RT (as his code sets them to NULL)...
This further demonstrates why I can't really file report bugs, to a large extent... It's kind of a pain, but at least I can run my apps with great success. That said, maybe when I rebase during Wine-8.x development cycle, I can test against Wine-Staging and at least do some bug reports, where applicable.
If they are highly use-case specific, like you depend on old versions of
Linux
libraries or whatever, we might not be able to address them, still we'd
love
to hear about them.
Highly use-case specific in that I only care about running Proaudio apps (for personal use). I will make use of any kernel or userland functionality/advantage to do so. I will employ hacks in Wine, when needed (even if a bit icky and tricky)... But no, I don't use any kind of proprietary Winelib apps, no odd-ball compilers or anything like that... I use Archlinux, a fairly vanilla system, and While I do use a custom kernel, nothing too exotic: Preempt-rt (6.0.x), some backports from 6.1/2, a few other bits (stuff that is, or will be upstream)...
For me, the 3 biggest things that I would like to see upstream Wine implement / support are:
#1 - better handling of Windows Synchronization primitives (this is tricky to not be platform-specific.) #2 - Proper mapping of Windows Scheduling to Linux/Unix Scheduling (both nicess AND RT scheduling) #3 - Multi-threaded Wineserver (requests, replies and APCs are a huge bottleneck for single-threaded wineserver)
I have things in place to handle all of these things (to varying degrees), but it's all very hackish and certainly not suitable for upstream... I understand a lot of the challenges for upstream here, none of the above are easy to address - but are all showstopping issues with being able to use Vanilla Wine, or even Staging.
Honestly I hope upstream reconsiders multi-threaded wineserver at some
point. I know it's single-threaded for stability/simplicity, but it's a real bottleneck in some cases.
I hope so too, Gabriel... Personally, I think Torge's multithreaded wineserver code demonstrates that there could be some viable solution. ~ I've had ZERO instability using those patches (initial issue aside). ~ I'd like to see an approach like that, but one that also handles APCs too... Lots of things can be handled by a single thread, but the server requests/replies && APCs can't be, at least not when using some heavier applications. (Ableton Live 11 is a fantastic example, as are certain VSTs).
Cheers, sorry for the lengthy rant guys ;-)
Jordan