nine7nine / Wine-NSPA

Wine-NSPA: Proaudio & RT focused builds of Wine(-TKG)... WARNING: Forced Pushes && Resets..
20 stars 2 forks source link

How to install? #11

Closed kz-n closed 2 months ago

kz-n commented 2 months ago

Sorry if im being dumb but i cant seem to find whats the correct way i should install this? I am using EndeavourOS

nine7nine commented 2 months ago

EndeavourOS is Arch-based, so building any PKGBUILD is done using makepkg -si

  1. clone the repo
  2. cd into the wine-nspa-8x-git directory
  3. makepkg -si
kz-n commented 2 months ago

i tried to do that and like, nothing seems to work trying to do "wine explorer" returns wineserver: using server-side synchronization. sorry but i've never compiled wine before I don't know why it woudl cause this issue.

furthermore if i close that process and start one again i get Fatal glibc error: allocatestack.c:333 (allocate_stack): assertion failed: size != 0

nine7nine commented 2 months ago

Okay, so you got it to compile (good).

However, the error you are seeing is because you haven't setup your environment:

https://github.com/nine7nine/Wine-NSPA/wiki/Wine-NSPA:-Environment-Variables-&&-Feature-Setup

you need to set all of the wine-related environment variables. So that you aren't using wineserver: using server-side synchronization, and also so that all other wine/RT related stuff is set correctly. it has to be system-wide or you get that error;

Fatal glibc error: allocatestack.c:333 (allocate_stack): assertion failed: size != 0

check your systemd configs, as well. As mentioned in the same article.

Lastly, you may need to adjust WINE_RT_PRIO=80 to another value, based on how your system is setup (eg: what is jack or pipewire's RT prios?)... On my system, my priorites go something like this:

audio card = 98 JACK/Pipewire = 89 Wineserver/Critical thread = 80/78 USB = 75

and so on... So my audio hw && soundservers run at a higher priority than Wine, but Wine is next highest.

kz-n commented 2 months ago

OK, first of all thank you so much for making this possible, and secondly for making it surprisingly easy to setup. Now wine explorer worked, i will see if ableton manages to start.

On another note, is it possible to a) add wine-nspa to the AUR (or similiar) and b) to make an automated install script ( c) possibly both ) ? Assuming this is all that i had to do, seems pretty fair to have it in a script. If needed i could try making something along those lines

kz-n commented 2 months ago

Also is it possible to have wine-nspa alongside normal wine? I fear that these new changes might break software that relies on wine, as wine-nspa seemed to have drop in replaced the original, this would also be helpful for using something like Bottles, PlayOnLinux or Lutris (which is what im using)

kz-n commented 2 months ago

So normally I use FlexASIO, even though WineASIO exists (haven't got it to work) because its still better than ableton's built in audio, but FlexASIO isn't recognizing pipewire or my audio devices in general (one I use is called Audio interno Stereo analogico (italian for Analog Stereo Internal Audio) ), on top of that ableton cant seem to open anything else, apart from default wave which sounds... terrible

https://github.com/nine7nine/Wine-NSPA/assets/64893077/3f0bc5fb-ba1d-45a5-b0b6-ed58c83b2f6b

What should i do?

nine7nine commented 2 months ago

You're welcome. Yeah, it seems intimidating at first, but it's actually not too bad to build or setup. build it, modify a couple of config files (and of course, some unrelated setup for proaudio on linux).

Well, as far as AUR -- I'm not inclined to do that. I am a former package maintainer in the AUR, but I don't have a lot of time for that -- and I prefer to be contacted on Github for any of my related PKGBUILDs... I have a lot of other things on the go, besides just my Wine-NSPA stuff, so I try to limit it to being available here. I'd prefer it stay that way.

As far as a script, i mean it's already pretty simple; clone the repo (or update locally via git pull), cd into the directory and makepkg -fsi on subsequent builds... all of the other tricky configs/scripting is handled by wine-tkg's build scripts... i don't think a script to further automate this is necessary at all.

Regarding, wine-nspa being a drop-in replacement. Yes, that is exactly what it is. Due to different versions of wine co-exisiting on a system; it's not unheard of to completely trash a wine-prefix by mixing and matching... I'm not going to change my own setup to start messing around with that -- and it would open the door to me having to test a bunch of configurations and crap that I do not want to get into (including bottles, lutris and stuff like that)...

kz-n commented 2 months ago

I was more of referring to wine-nspa being able to be used without being the system installed wine. Im not sure how that could be possible, but via lutris i have selection for various flavours of wine to choose.

https://github.com/nine7nine/Wine-NSPA/assets/64893077/8c22a796-9925-4ecc-9e5f-d2e74df8d888

Also this is how my setup works with the default lutris wine (wine-ge 8.26)

kz-n commented 2 months ago

Ok well, WineASIO managed to install here so, I guess its fine

nine7nine commented 2 months ago

You do have the option of changing wine-NSPA's installation path via customization.cfg. eg:

#### EXTERNAL INSTALLATION SETTINGS - !! ONLY AFFECTS MAKEPKG !! ####

# Set to true to install into external path instead of /usr. This allows you to install multiple different versions in parallel.
# !!! Don't forget that you'll have to use /opt/wine-something/bin/wine instead of just wine (same for winecfg etc.) !!!
_EXTERNAL_INSTALL="false"

But i have not, won't test this. you would set that to true - then have to play around with your WINE_PREFIX= settings, or however Lutris handles that... Again, I'm not getting into setting up things that way -- because I don't bother with any of those silly wine wrappers.

BTW, using PulseAudio is just plain wrong. Same goes for using FlexASIO routed through PulseAudio -- look at your latency 289ms. That isn't usable by any stretch of the imagination. WineASIO is a hard-requirement for an ASIO-compatible driver in Wine, period.

On my system I'm using 5-10ms of latency.

kz-n commented 2 months ago

I don't do latency critical things, so honestly i usually dont mind high latency. I'm more interested in my projects not underrunning constantly cause that just makes it unusable

nine7nine commented 2 months ago

ah, so you don't doing any live recording (midi or input)?

I don't get any xruns from ableton live, other than the occasional one or two when loading something, which is a common issue, not exclusive to Wine or anything like that. Happens with native software to some degree or another.

kz-n commented 2 months ago

i have a not top of the line computer, and my projects usually have nested effect racks (which sends ableton in an uncontrollable spiral of lag) i do midi from time to time but its not my priority, still if i can squeeze all performance i can get, i ain't complaining, in fact if theres anything i can do i can try to do it (i am now looking at #4 and just set the options.txt)

nine7nine commented 2 months ago

Well, the biggest problem with Ableton Live running in Wine is the couple of busy threads that it has -- that consume CPU to some extent constantly, which can cause your CPU to run hot. something to watch out for. This happens on all versions of Wine. It's the biggest blocker ATM. Not easily solvable either.

you may have some succes with options.xtx and messing with some of those settings. In particular some machines benefit from -DontCombineAPCs

honestly though, if Ableton Live was a hard requirement for my music production -- I'm not sure I'd run it in Wine unless the busy threads issue is resolved... It's the biggest PITA from my perspective

kz-n commented 2 months ago

I've produced most of my music through ableton live 11 on older versions of wine and linux (was years ago) without even knowing i could install stuff from winetricks to make it dramatically faster, This effectively means that that setup had about the same amount of performance as my secondary celeron laptop (N4020U) has on windows. Yikes. For me even just the setup i had with FlexASIO was usable, with wine-nspa i immediately noticed even the startup was faster, WineASIO is helping a lot, i have a benchmark project that ran shit on flex and the integrated audio drivers but like this it runs fine apart from some underruns here and there, which i could fix by raising the buffer size (right now its 1024 with a bazillion inputs and outputs), but the settings app isn't saving anything (Might look into the registry)

kz-n commented 2 months ago

honestly though, if Ableton Live was a hard requirement for my music production -- I'm not sure I'd run it in Wine unless the busy threads issue is resolved... It's the biggest PITA from my perspective

What would go into fixing this?

nine7nine commented 2 months ago

I've produced most of my music through ableton live 11 on older versions of wine and linux (was years ago) without even knowing i could install stuff from winetricks to make it dramatically faster, This effectively means that that setup had about the same amount of performance as my secondary celeron laptop (N4020U) has on windows. Yikes. For me even just the setup i had with FlexASIO was usable, with wine-nspa i immediately noticed even the startup was faster, WineASIO is helping a lot, i have a benchmark project that ran shit on flex and the integrated audio drivers but like this it runs fine apart from some underruns here and there, which i could fix by raising the buffer size (right now its 1024 with a bazillion inputs and outputs), but the settings app isn't saving anything (Might look into the registry)

Yeah, startup is always a bit slow -- but should be much faster in Wine-NSPA due to a number of differences between my builds and every other build of wine out there. Things like: much different RT implementation, multi-threaded wineserver, and how some memory-related stuff is handled.. on top of all of the Proton stuff, like Fsync. It's just a much different beast.

I'm not sure what you mean by the settings app isn't saving anything -- do you mean connections to system inputs/outputs?

nine7nine commented 2 months ago

honestly though, if Ableton Live was a hard requirement for my music production -- I'm not sure I'd run it in Wine unless the busy threads issue is resolved... It's the biggest PITA from my perspective

What would go into fixing this?

Well, it's a complex problem and is tricky to debug, as well... Wine is essentially doing all of the NT kernel stuff in a single-thread (Wineserver), and it hasn't fully re-implmented everything in NT either... I get around some of htis with the shmem multi-threaded wineserver -- but in Ableton's case, it still won't resolve the busy threads.

Debugging it is hard. Attaching to the actual threads crashes Wine/Ableton, and trying to debug it in a more general way is much too verbose. I'm certainly not the only person that has looked at this -- and so far, there is no solution. Ironically, Ableton Live is pretty much the only application I've encountered that has this issue. Some poor interaction between Ableton and Wineserver, not sure of the cause exactly.

I have some patches (not applied by default) that do actually reduce CPU overheard with Ableton Live (and some other heavy apps), but again -- not a solution to this particular problem. I'm looking into another debugging option, using GDB directly (along with some patches for Wine), and maybe that will help identify the cause -- but even then; who knows if it's fixable for now. It could be a case where Wine needs a larger set of architectural changes. idk.

nine7nine commented 2 months ago

I'm going to close this issue - since it's been resolved. you can still comment though

kz-n commented 2 months ago

I've produced most of my music through ableton live 11 on older versions of wine and linux (was years ago) without even knowing i could install stuff from winetricks to make it dramatically faster, This effectively means that that setup had about the same amount of performance as my secondary celeron laptop (N4020U) has on windows. Yikes. For me even just the setup i had with FlexASIO was usable, with wine-nspa i immediately noticed even the startup was faster, WineASIO is helping a lot, i have a benchmark project that ran shit on flex and the integrated audio drivers but like this it runs fine apart from some underruns here and there, which i could fix by raising the buffer size (right now its 1024 with a bazillion inputs and outputs), but the settings app isn't saving anything (Might look into the registry)

Yeah, startup is always a bit slow -- but should be much faster in Wine-NSPA due to a number of differences between my builds and every other build of wine out there. Things like: much different RT implementation, multi-threaded wineserver, and how some memory-related stuff is handled.. on top of all of the Proton stuff, like Fsync. It's just a much different beast.

I'm not sure what you mean by the settings app isn't saving anything -- do you mean connections to system inputs/outputs?

I did some random things and it saved my settings, Although it's not actually changing my buffer size, I assume its due to my jack buffer size being 1024 (tried to change it from qjackctl and i heard the sounds of hell so i quickly reverted it) as in the config it states 2048 but in ableton i get 1024.

I have some patches (not applied by default) that do actually reduce CPU overheard with Ableton Live (and some other heavy apps)

How could I enable them? Curious to get all performance I can

Ironically, Ableton Live is pretty much the only application I've encountered that has this issue. Some poor interaction between Ableton and Wineserver, not sure of the cause exactly.

So i figure i will just have to hope some random update fixes it lol

I'm looking into another debugging option, using GDB directly (along with some patches for Wine), and maybe that will help identify the cause -- but even then; who knows if it's fixable for now. It could be a case where Wine needs a larger set of architectural changes. idk.

Is there some open discussion about this issue? I would love to be able to participate in it or at least understand whats going on

nine7nine commented 2 months ago

I did some random things and it saved my settings, Although it's not actually changing my buffer size, I assume its due to my jack buffer size being 1024 (tried to change it from qjackctl and i heard the sounds of hell so i quickly reverted it) as in the config it states 2048 but in ableton i get 1024.

Right. your audio settings are handled on the linux-side/audio server side -- not during runtime in Wine (well, excluding midi, some routing stuff, etc).

How could I enable them? Curious to get all performance I can

I'll try to add a Wiki page on how to do this in the next day or so. It's not hard, but requires a couple of manual steps: building an external library, then moving 2 patches into wine-nspa/tkg build system. then rebuilding... The gist is that I wrote code to replace Wine's pthread_mutex implementation, along with making a few related changes.

So i figure i will just have to hope some random update fixes it lol

Pretty much, unfortunately. Sometimes these things take time. If it was something that affected Valve/Steam - I'm sure it would have already been fixed, but proaudio isn't exactly a priority for them, CodeWeavers, or Wine developers. It's also possible that with all of the upstream work on NTSync - we may see it resolved, but only time will tell.

Is there some open discussion about this issue? I would love to be able to participate in it or at least understand whats going on

Nah, It's come up in a bug report or two and it's been discussed on Wine-devel mailing list a couple of times. Not really something that requires paricipation, or is even an active discussion atm.