L_Proaudio Project: Wine-L_pa + Linux-L_pa

Question

Announcing L_ProAudio;
L_ProAudio
The L_ProAudio project aimed at Vastly improving wine-enabled Windows VST/ASIO applications to run more seamlessly and integrated in a Gnu/Linux environment. EDIT: it ALREADY accomplishes it's aims for the most part, with the exception of WineASIO / wine-rt / wineserver bound applications ~ which are stuck using the 'wineserver bottleneck'. ~ but this is being looked into so be patient...
NOTE: there is lots of info (below) and at SF.net wiki + readme.
I've started some docs for the wiki, but you'll have to wait a few days for that.
This project is split into components:
1. Linux-L_pa is the specially tweaked kernel. This kernel is tweaked for RT (Realtime Linux), but more specifically 3.6.11-rt25-1-rt patched with a few 'cherry-picked' patches (by me) from various useful sources. These sources include; Muse Research, Mao Tao / Google / google, while others will be identified in the patch, themselves. These were all then applied and/or reworked in order to work nicely. This kernel is designed to work with wine-L_pa and does so, very well.
2. Wine-L_pa is a highly modified version of Wine. It's patches were also cherry-picked from Muse Research / Codeweavers, my own patches or otherwise identified, respectfully. This version is based on 1.5.21 (and thus all patches were re-based...). A brief log of useful stuff included;
- new threading/priority model; L_RT_THREADS bool (env variables for new prio/threading enablement)
- ntdll use syncronisations for pipes  (<-- needs investigating by devs, but provides jack like synchronization to wine-apps)
- Rendering vastly improved for vst plugins (and wine in general, no flickering on move/scale)
- much better handling of threads/priorites
- signicant reduction in CPU usage (in general)
- much more stable than upstream wine
- fixes for disk geometry io ctl
- fixes for DnD
- fixes for metacity / hidden windows / etc...and much more
FSThost from SVN on SF.net will also be useful, since it integrates with L_pa-Wine's new priority mapping / threading code via env variables (that fsthost handles)
https://sourceforge.net/projects/fsthost/
< triplesquarednine (_AT_) gmail (_DOT_) com
Wine-L_pa is available in the AUR:
https://aur.archlinux.org/packages/wine-l-pa/
Linux-L_pa is available at sourceforge project page, but will be available in AUR, in the next day or so (along with nvidia-l-pa, for binary driver rt-users, like myself)
http://sourceforge.net/projects/l-proau … z/download
report back issues, patchwork, etc... have fun
Last edited by triplesquarednine (2013-01-05 13:28:23)

Answer 1

I don't know how many people are following this thread, but i have several areas of news;
1. I am working on figuring out issues with Cockos Reaper (including being in touch with them, plus kindly given an NFR'd copy for reaper testing puroses.
2. I am working with Upstream wine and in the next release or two - some of my patches will be merged upstream (although not the _best_ ones), mostly one's that fix bugs in upstream wine. ~ that's okay though, we still have a proaudio geared L_pa-Wine anyway. (which is part of the point, in the first place - i knew they would reject the best patches from L-pa - but this is entirely why L-pa is a downstream project ~ that will continue to work with upstream).
3. FSThost fully-supports my project with integration of L_RT_THREADS and the pipe_sync support. ~ it is the de-facto standard for hosting VSTs in L_pa.
4. WineASIO needs to be looked at as faw as hosting DAWs. FSThost seems to be a more direct path and handles prios properly, wineASIO does not (with or without wine-rt patch apllied to L_pa-Wine)- but as far as single hosting + WineASIO ~ just pass the env L_ variables and you should be fine. (the threading/prio mapping gets trickier with DAWs and needs to be investigated / tested quite a bit more - before i can promise your wineDAW will run well).
5. I've got a good amount of testers for both system components, some having great success, some still having issues (to be expected, this is experimental software ~ and an *alpha" project. ~ i am making progress very quickly though, so be patient.
6. I _think_ in 3.8-rt ext4 _may_ be alright with some tweaking. noatime,data=writeback are almost certainly going to be requirements though, (since they reduce latency / increase performance ~ albeit at the cost of a little data integrity...  so it's upto you what you wanna do in this regard.  Ext4 is not very performant for these kinds of uses (with RT and Wine). Using a different file-system could fix the problem ~ but not many of us, have that choice always.
7. 1 system (out of many testers) is incompatible with the revert-stable-page-write patch, if you get hung on boot - with a stop on loading ramdisk ~ you need to revert it and re-compile.  Unfortunately, this is _likely_ to mean ext4 will be a much bigger bottleneck on your system ~ so you will need to look into alternative ways of taming the latency inducing / xruns causing beast that is ext4.. ~ but we will get upstream ext4 tamed in the next couple of releases (as forementioned). ~ but note: i am looking into the 1 system that hangs on boot (i just need logging/crash info, and a bit of time).
I am also looking into Btrfs support, although there is no rush for that (since i am not using it). (
anyway,
more to come
Jordan
Last edited by triplesquarednine (2013-01-04 18:39:02)