You are not logged in.

#51 2013-04-04 18:07:59

triplesquarednine
Member
Registered: 2011-04-12
Posts: 630

Re: L_Proaudio Project: Wine-L_pa + Linux-L_pa

Pajaro wrote:

Thank you for all your work, triplesquarednine. I believe that right now this forum is the most relevant place to keep an eye on for linux musicians.

(sorry for the late response, i've been crazy busy the last long while)

thanks. I'm not sure if this is the most relevant place and/or stuff happening. but your interest is appreciated, regardless. wink

I've updated L_Pa stuff in AUR ~ I should have new nvidia-l-pa on SF.net later today / tonight.

From both linux-l-pa and Wine-l-pa I have removed a few patches (and added 2 to linux-l-pa).

this linux-l-pa release seems to be quite nice. I scooped up the zen patch for allowing -march=native (and thus -mtune=native) flags to be added to kernel compilation, simply by selecting 'y' when prompted at the start of the build. (or via make menuconfig, etc). I did this rather than adding the patch suggested on page 1 of this thread, because using -march=native is simpler / more convenient for most people, i think. The other new patch sched-Fix-select_idle_sibling-bouncing-cow-syndrome.patch ~ fixes some (long-time) annoying behaviors that i've experienced on my machines, to varying degrees. COW here, stands for 'copy-on-write' ~ so this has an effect on things like Device Mapper subsystem in kernel, i would assume cow file-systems like btrfs.... but where i notice the benefit as an end-user;

- my multi-card reader was painfully slow without this patch.
- VMware tends to make the desktop 'hiccop' during certain transactions. ( *without* this patch)
- certain file transactions were slower without this patch.

So both new patches are applied by default.... I've also got 1 patch to rebase + a couple of others that will probably slip into a future 3.8.x-l-pa release, once i am confident they are general-enough to be used by everyone / anyone.

I've also got something else interesting brewing, but details on that will be at a later date - as it's not ready for 'show and tell' quite yet smile

cheerz

Last edited by triplesquarednine (2013-04-04 18:15:45)

Offline

#52 2013-04-04 21:59:31

triplesquarednine
Member
Registered: 2011-04-12
Posts: 630

Re: L_Proaudio Project: Wine-L_pa + Linux-L_pa

I just updated nvidia-l-pa on SF.net. it is still 313.18 ~ but i will be adding the latest driver (as well), later tonight.

Offline

#53 2013-04-05 00:37:19

Thaodan
Member
From: Dortmund, Nordrein-Westfalen
Registered: 2012-04-28
Posts: 438

Re: L_Proaudio Project: Wine-L_pa + Linux-L_pa

Are there some patches applied to your wine build that are usefull for general use (gaming etc)?


Linux odin 3.13.1-pf #1 SMP PREEMPT Wed Mar 5 21:47:28 CET 2014 x86_64 GNU/Linux

Offline

#54 2013-04-05 03:01:09

triplesquarednine
Member
Registered: 2011-04-12
Posts: 630

Re: L_Proaudio Project: Wine-L_pa + Linux-L_pa

Thaodan wrote:

Are there some patches applied to your wine build that are usefull for general use (gaming etc)?

Can you give an example of what would be 'useful' to you?

I mean I don't include any of the patches that specifically make certain games run or anything like that, nor do I include the RGL patch, in-process-wineserver or any of those d3d type patches / hacks.  (I'm aware of a bunch of them, but i'm not a transgamer).

I do use wine for the odd 'general' application, but not gaming specifically.

Offline

#55 2013-04-05 11:49:27

Thaodan
Member
From: Dortmund, Nordrein-Westfalen
Registered: 2012-04-28
Posts: 438

Re: L_Proaudio Project: Wine-L_pa + Linux-L_pa

With useful I mean general improvements of the speed of wine, that are useful when running non VST/ASIO applications.


Linux odin 3.13.1-pf #1 SMP PREEMPT Wed Mar 5 21:47:28 CET 2014 x86_64 GNU/Linux

Offline

#56 2013-04-05 17:52:20

triplesquarednine
Member
Registered: 2011-04-12
Posts: 630

Re: L_Proaudio Project: Wine-L_pa + Linux-L_pa

Thaodan wrote:

With useful I mean general improvements of the speed of wine, that are useful when running non VST/ASIO applications.

Possibly.

I haven't (really) done any extensive benchmarks, regarding common use / general applications but it would also depend on the app and if any of the patches benefit a given app. ie: the app is making use of windows stuff that are affected by the patches + what variables you are using with that app, if that makes sense to you (?). ~ i did one small benchmark (can't remember the name, off hand) which had to do with latency. I first tested without using any wine-l-pa variables and then after with wine-l-pa vars ~ when i compared the numbers, wine-l-pa with L_ vars had slightly lower latency, and the numbers (in ms) showed much less variance.

For example, wine-l-pa has the 'wine-rt' patch that maps windows scheduling policies to linux scheduling policies. ~ so if an app sets it's windows policies-  and this benefits the app (and maps well to linux), then yes, the app will probably benefit. Likewise you can use realtime scheduling policies for wineserver, which could be helpful in some scenarios...  you could also use the L_ variables; which allows setting realtime priority _without_ wineserver, and onto the apps themselves. (these patches affect/applicable to THREAD_PRIORITY_TIME_CRITICAL / 'rtl_Critical_Sections' in MS code...  setting L_RT_PRIO and L_RT_POLICY in conjunction (again) your app may benefit.

Some of the patchwork relates to apps / usage requirements where low-latency, apps being time sensitive, performance, depending on app, etc. And on the note of gaming, i would tend to think 'critical sections' are used quite a bit with D3D, as i am pretty sure i remember looking at the old RGL wine patches (including the guy's debugging tools) once upon a time, and i remember seeing that kinda thing... rgl code is still available, but i can't seem to find the patches (specifically that i was talking about);  http://www.aewi.info/rgl/   ... rgl is just for Wow though, i think.

You know, if this is something that interests you, you could try to benchmark some of this stuff - i just don't really know what you have in mind? ... I don't have games or anything like that installed, but if you chipped in and found some worthwhile benchmarks (that run in wine) i would probably give them a spin, if they provide actual data / stats.

food for thought.

Last edited by triplesquarednine (2013-04-05 17:56:43)

Offline

#57 2013-04-05 19:06:32

Thaodan
Member
From: Dortmund, Nordrein-Westfalen
Registered: 2012-04-28
Posts: 438

Re: L_Proaudio Project: Wine-L_pa + Linux-L_pa

Thanks for your informations. I thought about multi player games where many data income in a short amount of time.


Linux odin 3.13.1-pf #1 SMP PREEMPT Wed Mar 5 21:47:28 CET 2014 x86_64 GNU/Linux

Offline

#58 2013-04-06 13:33:45

triplesquarednine
Member
Registered: 2011-04-12
Posts: 630

Re: L_Proaudio Project: Wine-L_pa + Linux-L_pa

@Thoadan

No problem, i hope it was useful.  I am not sure about multi-player games - what i would say, is your could try wine-l-pa and see if it makes any difference.

I may dive into testing that kinda thing at some point ~ as well, i have considered offering PA support ~ although, i haven't gotten around to adding it.

General note / comment:

I've updated nvidia-l-pa on FST.net to 313.30 version. (as well, nvidia-313.18 is offered and patched for 3.8 kernels).

https://sourceforge.net/projects/l-proaudio/files/

cheerz

Offline

#59 2013-04-10 01:52:32

triplesquarednine
Member
Registered: 2011-04-12
Posts: 630

Re: L_Proaudio Project: Wine-L_pa + Linux-L_pa

triplesquarednine wrote:

I've also got something else interesting brewing, but details on that will be at a later date - as it's not ready for 'show and tell' quite yet smile
cheerz

"The cat is out of the bag!" wink

http://linux-audio.4202.n7.nabble.com/F … 84333.html

Between Pawel (FSThost dev) and myself, have been working on a lot of interesting changes are in FSThost 1.5.0 release. (for example, 64bit VST support, self-handling midi progrm changes, etc).  Some have been mentioned previously in this thread (as we were exchanging ideas, testing code, etc), minus the 64bit development which is very new. The gtk_toolbar isn't merged yet, but 1.5.0 does have a lot of substantial new features, a ton of bugs fixed / code cleanups, etc.

Unfortunately, wine64 is somewhat broken on GCC-4.8.0 *unless* you set optimization level to -O0 (-O2 / -O3 will result in wine64 not working, at all). Fortunately, it's been reported and i also verified another persons bug report (on WineHQ). So until that is figured out (or you are not using gcc-4.8.0, which Archlinux is), you probably won't easily be able to use fsthost64/wine64. (but note: this does not effect wine32, so no worries there).

anyway, there is a bunch of other stuff brewing, but i will wait until a more appropriate time to discuss some other happenings, when it is a bit more mature.

cheerz

Last edited by triplesquarednine (2013-04-10 14:56:21)

Offline

#60 2013-04-10 18:51:57

triplesquarednine
Member
Registered: 2011-04-12
Posts: 630

Re: L_Proaudio Project: Wine-L_pa + Linux-L_pa

nvidia update: I've added the latest nvidia beta driver to SF.net: https://sourceforge.net/projects/l-proaudio/files/

So to recap (on nvidia), currently on SF.net you can use 313.18(stable) / 313.30(stable) / 319.12(beta) drivers with Linux-l-pa kernel (3.6.x and 3.8.x series) ~ All that is required is having the correct/matching nvidia-utils or nvidia-utils-beta packages installed.

I'm using the 319.12 driver, but i want to give the end-user options, just in case - so i will keep the various versions available, just in case someone needs something specific.

Liux-l-pa update: I've also updated linux-l-pa, i just swapped one patch for another (gcc optimization stuff), noted on AUR comments.


Wine64 update: I'm still waiting some more feedback @ winehq on brokern wine64 support - but a couple of the reported bugs have now been linked as duplicates that were related (by admins/developers), so i expect (hopefully) in Wine-1.5.28 these problems will be addressed. (but i haven't seen any relevant patchset hit wine-patches list yet, so we'll see what happens.).

EDIT@:

another update on Wine64 - I'll be running git bisect on gcc to try to narrow down a possible commit, that breaks Wine64. I was asked to help by one of the wine-devs who focues on these types of (compiler) issues - so i am going to set aside / find some time to help find the bug and/or a commit that might point us in the right direction, if the bug happens to be in Wine (i'm not sure, but i am leaning towards gcc-4.8.0 screwing up, since it's a pretty hefty and new release)...

Last edited by triplesquarednine (2013-04-11 13:57:05)

Offline

#61 2013-04-13 17:00:18

triplesquarednine
Member
Registered: 2011-04-12
Posts: 630

Re: L_Proaudio Project: Wine-L_pa + Linux-L_pa

another update on gcc-4.8.0 breakage on wine64;

I've given up on trying to identify or fix this issue. Instead, i have added -O1 flag to wine-l-pa so that at least wine64 works... I've spend 30+ hours on compiling wine trying to figure out which flags may be breaking -O2 optimization level, to no avail.

my feeling is that since gcc-4.8.0 is 'out there' and in use, now - Wine-devs need to address all of the warnings being thrown by gcc-4.8.0, since it could easily be some of them breaking wine64 + higher optimization levels. Anyway, i am not willing to spend any more of my (limited) time on this issue, so for now - wine64 is severely broken with -O2 flags or higher, wine-developers are well-aware of this - so lets hope they fix it smile

Offline

#62 2013-05-29 13:29:48

triplesquarednine
Member
Registered: 2011-04-12
Posts: 630

Re: L_Proaudio Project: Wine-L_pa + Linux-L_pa

I decided i should give a brief update - since i have not been too active, here in the arch forums, for the last while ~ but make no mistake -> i am quite active in working on L_Pa stuff. smile  A few (up and coming) updates;

Wine L_Pa (things I am working on, or have working but not released yet))

- PulseAudio support; 

Already merged locally into wine-l-pa... works as expected. Although, i don't use PA - i've wanted it for a while, just for the odd testing purpose. Others may find it useful, so i will include (but probably disabled. ie: "--with-pulse" at configure/compile time will enable it).

- support of native Windows drivers for USB tokens 

Already merged locally into wine-l-pa. Specifically, what i am after with this support is Pace Anti-Piracy "iLok USB dongle" support. However, this isn't ready for 'prime time' _yet_. I have the majority of code in place working, but i still have some work left to do here. Many companies (proaudio vendors) use Ilok, but it also isn't uncommon for other S/W vendors to have a USB key (based on Pace's technology), so this should allow many keys to work. Right now, winedevice searches for "TPkd" driver, which is tpkd.sys (Pace USB token). Here is what it looks like when no tpkd.sys is found;

err:winedevice:ServiceMain driver L"TPkd" failed to load

if it is found, Wine will attempt to use the device -> all of that code/logic is in place, I'll be testing it this weekend... One final note on USB token support ~ It will break existing wine prefix. (well, not totally, just "mount manager"). ie;

err:winecfg:open_mountmgr failed to open mount manager err 2 

A fresh prefix fixes the issue. (so no big deal). again, this will an be optional feature, enabled by using "with-usb" at configure/compile time. it also requires 'lib32-libusbx' from AUR, on 64bit systems, otherwise compilation will fail due to missing that dependency.

- initial support for things like; KeInitializeEvent, KeInitializeMutex, Ktimer and friends, using 'pthreads' over native win32 threads (pthreads are required, win32 threads are too slow). This has been enabled due to trying to support USB tokens. 

- Support for win32 "FILE_FLAG_NO_BUFFERING" & "FILE_FLAG_WRITE_THROUGH" mapped to O_DIRECT / O_SYNC (linux counterparts).... and i am investigating getting "MOVEFILE_WRITE_THROUGH" enabled, since an app i want to use needs it. (below)

- Initial Ableton Live 9 support. smile  Don't get too excited yet, since Ableton really wants "MOVEFILE_WRITE_THROUGH" (part of "MovefileEX" in Win). Ableton actually runs great here, except for when it needs to do movefile_write_through (which makes it puke xruns, unfortunately.). Anyway, i am going to see if i can get some hack/patch in place for this, but it may take a little while.

- More Named Pipes support, added. - I still have more named pipes patches that i am working on, but the ones that have been included (actually, WILL be included, but are working locally) speed up certain installers by quite a bit. But generally, Wine doesn't support named pipes all that well, which means named pipes behavior is largely undefined. (which probably has an impact on performance / Wine handling them correctly).

i've got a few other wine-related bits that i am working on as well, these are just the major ones wink  ... Also, gcc wine64 bug has been fixed. (as well, as 2 other bugs in wine that i reported + i have a workaround for another CPU architecture related bug that i am testing. (works well so far!).

cheerz

Last edited by triplesquarednine (2013-05-29 13:44:04)

Offline

Board footer

Powered by FluxBB