LinuxMusicians

FalkTX, after patching wine I have problem with Reaktor 5. It tells me it needs processor with SSE2 support. It worked before the update so something is broken now...

ninez wrote:To clarify...

Thanks for the clarification. I tend to get excited when stuff which is important to me gets done or close to done, that's why I used word "flawlessly".

FM8 works great here, with upstream wine nad KXstudio, so I guess it will work great with your modifications too - I will tell more when I try it. On the other hand Guitar Rig crashes carla-discovery and refuses to work. I'm curious, why disable reflektor, is it just crashing or there are other reasons for this advise? I hope Kontakt can be run without issues, now it freezes on note on.... we will see.

Todays update (or rather "the one I did today"). But on the second thought it may be that I upgraded Reaktor to newer version, so sorry for confusion. I thought it may be related to L_ProAudio. Sorry for confusion... anyway, would be great to fix this Maybe in another thread though.

Lol, I found a "bug". Somehow default Windows version in winecfg changed to Windows 98. Mod, please delete my last three posts to keep this thread clean. Also, FalkTX thanks for your time.

@ Everybody.

I've updated sf.net with new sources, i've added a few things to the readme on sf.net and update the one's inside. I included the fixed patches, but NOTE: wine-rt is disabled in the xxx-prepatched.tar.gz ~ while is because it has proven to be unnecessary with the new multi-threaded model, thus isn't really required any way. (in fact, it was screwing me up today, as i was sifting though some vsts dlls i haven't touched in a long time - wine-rt + new wine would cough in certain circumstances... i scratched my head, then compiled it with wine-rt removed... did some more testing, problem gone....went and tested my regular array - all working nicely.... Wine-rt patch is still in the Arch_n_patches.tar.gz though.

the link/files are as follows; https://sourceforge.net/projects/l-proaudio/files/

wine-L_Proaudio-prepatched.tar.gz < pre-patched sources. ready to compile, like usual wine
Wine-L_Proaudio-Arch_n_patches.tar.gz < pkgbuild for archlinux, which includes patchset ~ and revision, thank you FalkTX

I've also decided to deprecate the MUSE_ symbols from the sources. Quite frankly, i don't want any trademark hassles - and that is clearly associated with them, if they have a problem with that they can contact me, i have no issues. either way, i am happy to oblige.

The new names are as follows, the env Variables are used like so;

env L_RT_THREADS=1 L_ENABLE_PIPE_SYNC_FOR_APP=1 foo (<---- foo is your wine app/plugin)

without doing this, your app is not using the new multi-threaded model.

There are also other env variables, they are found in the patchwork for that marked; 0054-xxxxx.patch...

I won't be packaging new kernel sources for a few days (after more testing, more current dogfood/kernel ~ which is promising). but obviously, my current sources and patches are on sf.net. I'm telling you guys though, i've done my homework on what Wine likes and what it does not like, it loves my modified kernel (because i toasted a really big bottleneck). ~ As i have said from the beginning, this isn't just use one but not the other; for _real_ results, you need the pair.

I've made some progress, some notes, as well as added an update to my thread (in these foums) about L_ProAudio.

Some of it is _very_ relevant reading for those interested in the project;

http://linuxmusicians.com/viewtopic.php ... 448#p35448

I cover a bit more about how it works, where we currently stand with this software and interraction with WineDAWs, etc. Basically, important stuff

lets keep our comments about this in that thread from now on too, since this thread's title isn't related/descriptive.

Thanks

ok brother call me a dumb ass but im new to arch. i installed the Wine patch from aur. and i have the link to your SF project. How do i install the RT kernel. I downloaded the packagebuild file and the rt kernal file. unzipped and put all in the same directory. from term i issued makepkg and i get

install file (linux-rt.install) does not exist.
i know i did something dumb
help

Ok It was late and i was tired.. I havent used SF in a long time. Realize i need to use SVN to checkout your packages. Only problem is i cant figure out the proper address keeps getting rejected. Most projects in the wiki have SVN checkout instructions. For us Dumb asses that would like to help test this out could you please update the wiki with checkout instructions.. I have several test machines. one is even a 16 core opteron with a 16 bay sas. I can build and destroy installs at will. along with many firewire and usb pro interfaces to test with.

I am not a Developer. I build Network Infrastructure for a living. Not a coder. But i can deffinately supply you with bug reports. I own over 100 vst's and many free one like lepou amp sims

thanks

also interested in instructions how to build the Kernel in ARch

Sorry guys for the delayed response.

I've been really distracted / busy - beyond belief. ~ and in reality, Archforums in my thread is a better place for Archer's to contact me;

https://bbs.archlinux.org/viewtopic.php ... 9#p1214189

and or via email. (email in readme / on SF.net)

You don't have to use SVN for L_Pa kernel, it's right here;

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

"linux-l-pa-3.6.11_rt25-1.src.tar.gz" <--- archlinux package

untar, cd into directory, then: 'makepkg -si'

Wine-L_pa is in the AUR; 'yaourt -S wine-l-pa' (

or whatever utility instead of yaourt that you may be using to access AUR).

There are also nvidia-l-pa (313.09 series patched for RT drivers, but the pkgbuild isn't quite ready). I have to fix a mistake (in my packaging learning prcess, before i will make it available).

Read any and all info i have provided...

As a side note/rant: everybody really needs to get it into their brains (too), that this version of Wine is a significant departure from the Wine we are used to. (a deep architectural change, that is _good_ in the long run).

Until WineASIO can be fixed / re-written / etc ~ it can be dicey since it is using the worst possible mechanism (wineserver), to hack on it's priorities (basically, L_pa-Wine exposes wine-rt and wineASIO for what they are, band-aids/hacks trying to address a problem that L_pa-Wine fixes (but screws up anything reliant on wineserver).... this means complicated multi-threaded DAWs will probably run crappy. but note: this is not L_pa-Wine's fault. L_pa-Wine provides 'unix pipes' in Wine and correct conversion/mapping of windows priority scheduling to linux priority policies. But note: WineASIO is still perfectly suitable for single-hosted, standalone apps, etc. It's just _some_ daws that have issues... (also, in all cases if you have the option of .exe or .dll - always go with the .dll in FSThost ~ performance is much better). Remember that with wineASIO you have to pass L_ env variables to enable the new prio/threading model.

FSThost knows how to deal with this stuff. for example;

FL Studio runs prefectly here, as a *VST plugin* being hosted by FSThost. ~ I was compiling L_pa-kernel + Wine, while using 40-50% DSP load in Jack via FL (with loads being higher and/or lower at points) ~ my machine purring like a kitten here is a screenshot from when i was doing this;



note: i can hit 99% DSP load in jack with only a few xruns here and there... and note: some people seem to be under the impression that xruns are expected when hitting higher DSP loads with wine applications ~ but that is entirely false, they don't understand _why_ they are getting xruns ~ wineserver is 95% of the time the cause (on a properly configured system). Ever notice on Windows/Mac you can max out and _then_ you have problems??? ~ that is also how Jackd should be running with wine apps (to a very large degree), especially in the next few releases - when i get more solutions for _general end-users_. ~ ie: my system has a few extras that make a big difference, some which i couldn't recommend in good faith.

I hope this kind of spells it out for you guys, as to why i have started L_pa. it's not just wine, the kernel, etc either, it's about improving the whole stack / eco-system - connecting developers and finding gaps to fill with creative solutions that _work_ ~ I have several talented people that i am in contact with now too. ~ i upstream solutions that are good and/or present solutions that may _lead_ to proper solutions. (ie: you throw the right idea / code / prototype at someone who appreciates what you are driving at - 9/10 they will be inspired to tackle the problem, and provide a solution.. (if that makes sense).

The main person who belongs to the linux proaudio community is Pawel/FSThost Author. ~ he should be given a big thanks / appreciated for almost immediately seeing the value (where others have been slow to understand) - which is why he implemented L_pa within hours. (literally).. but the other people giving me a hand belong to the kernel development community, wine-devel, etc - which often gets into the _harder_ technical problems...

anway, i digress...

everyone on Archlinux should be fine to install Wine-l-pa and linux-l-pa (minus, nvidia-rt users whom will have to wait a few hours, anyway).

Jordan

and as an update there _is_ an nvidia-l-pa (nvidia-rt patch) packaged on SF.net

http://sourceforge.net/projects/l-proau ... z/download

I am not really a packager (nor do i want to be), so it needs fixing/looking over by an _actual_ packager.. ~ I'm too busy to be wasting my time with this kind of thing, when i am in the middle of working on taming 3.8 ext4 (for a possible generic performance improvement, that _could_ be included in a later L_pa 3.8-rt kernel release, as well as working on Wiki content ~ and life's little daily happenings).

the pkgbuild is borked on integrity checks and i am unwilling to dig around the web / archwiki to solve the issue (already did) and won't be uploading my kernel to AUR (either), until someone else lends a hand here. ~ having an nvidia-l-pa driver for end-users is a _hard_ requirement that needs to be looked after for end-users. Note: I don't have this problem locally, and my time is _wasted_ on packaging for Arch ~ i have bigger fish to fry / more important things to do + i've already got most of my ducks in a row.

anyway, it's there - i've also mentioned something similar in my Arch thread ~ so hopefully, someone realizes (who wants to use this stuff) that they should chip in ...

you can install the package though, you just have to skip integrity checks (makepkg -si --skipinteg). but that is unacceptable for AUR and i was getting side-tracked / annoyed, so i have dropped working on it to focus on other (**important**) things.

cheerz

...and about that FL Studio

that same session has been playing for hours now ~ while minimized/muted, as i am working away.

working away = compiling (usually a couple of things at once, ardour3, linux-l-pa, Wine-l-pa, nvidia-l-pa, updates, etc), watching videos flash videos, 4 busy workspaces, with many windows open, compiz-bzr + Gnome 3 + awn + more...

...still at zero xruns (currently 54% DSP load), completely happy, running in the background.

...but that number _could_ be 20-25% higher DSP (80% DSP + heavy CPU load) before i would be getting any xruns (and even then would only be a few inaudible ones).gotta hit 90%+ for any grains / distortion

linux-l-pa

...is now available in the AUR; https://aur.archlinux.org/packages/linux-l-pa/

note: nvidia-users, i will probably have a proper package up sometime over the weekend (when i can spend more time learning _proper_ archlinux packaging techniques ~ i am too busy at work this week, to do that or finish the wiki pages, right now.)

- I've made it a minimal patchest for now, but have more that i will be adding once they are proven to not be problematic for anyone.

1. one patch is commented out (revert-stable-write-page.patch) and should only be used by those interested / willing to dogfood their kernel/system, as well as people capable of collecting log files (and passing them back to me), debugging, patching, etc.

dogfood = may not work / be incompatible / cause issues / USE AT OWN RISK...

- i've included the patch because i have been using it for a very long time and (if it is compatible with your system), will have performance benefits to EXT4 (at a slight cost in data-integrity). it reverts 'stable page writes'. - stable page writes is a great feature, but is widely known (amongst kernel developers) to introduce a big performance regression on ext4 file-systems (in order to ensure data-integrity)

~ this feature did _not_ exist in the 2.6 kernel series (note: i highly doubt anyone who is using linux/wine for proaudio in the commercial / hi-end markets is using stable page writes. And outside of that market - Google, Oracle, Bao Mao and others have _all_ use this patch in certain environments for certain high-performance applications to avoid the penalty in using stable page writes in ext4).

I've found it to be very useful, so it is kept and available until ext4 stable pages is fixed.

A word to the wise ~ it's very rare that i see anyone discussing important details such as tuning your block devices via sysfs (in the context of RT). You really need (if you are serious about having an RT system that is good) to learn about CFQ (and kernel interfaces / tuning in general) and how you can better tune it for RT. I find it a little sad that i rarely see it even mentioned in any of the linux/audio resources around the web.

note: Suse, Redhat and other enterprise-class distributions have resources available on how to properly tune your system. Look for performance/tuning guides from them...ideally, you should be tuning, CFS (task scheduler) and CFQ (for block devices) while also running tests via cyclictest and latencytop on all changes (preferably repeatedly).

this kind of stuff makes a _big_ difference on your system, and the vast majority of system tuning, can happen during runtime. (by changing sysfs values for a given parameter). Anyway, here is one such example of a guide that describes various sysfs interfaces, that can be tuned;

http://doc.opensuse.org/products/draft/ ... ernel.html

this is sort of an introduction, imho (also a little dated) ... but it may spell out some of the basics, for those interested.

cheerz

nice,nice,nice,nice

next week, perhaps sooner, I'm going to test all this, and be sure that I'm going to report here to my LM Fellas.

Capoeira wrote:nice,nice,nice,nice

next week, perhaps sooner, I'm going to test all this, and be sure that I'm going to report here to my LM Fellas.

Cool man

if you run into any issues and/or have questions - do not hesitate to contact me (even directly via email, if needed).

cheerz

well i have both your wine and kernel running installed this morning from AUR so far i have to report just with recording audio and the sort from audiobox v22 v44 and 1818 round trip latency is 2.9ms (same machine win 7 10.5ms)
still working on getting win asio working for some reason it doesnt show up in wincfg gui. when i have more time ill work it out and try amplitube and guitar rig 5