L_Proaudio Project: Wine-L_pa + Linux-L_pa

triplesquarednine · 2012-12-31 20:51:03

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)

capoeira · 2012-12-31 21:18:03

pro-audio user here (unfortuanatly no dev/programer/scripter)

one question: why no AUR-packages?

Last edited by capoeira (2012-12-31 21:22:35)

jhernberg · 2012-12-31 21:38:18

I'll give you a hand to package this stuff, sounds very interesting.

Are you familiar with archaudio? It's a binary addon repo which in combination with aur could be to make distribution easier. There is also a freenode channel at #archaudio if you want to chat about this.

Just give me some days, since I'm on vacation right now.

triplesquarednine · 2012-12-31 21:47:49

jhernberg wrote:

I'll give you a hand to package this stuff, sounds very interesting.
Are you familiar with archaudio? It's a binary addon repo which in combination with aur could be to make distribution easier. There is also a freenode channel at #archaudio if you want to chat about this.
Just give me some days, since I'm on vacation right now.

No problem. I was hoping you might be inclined to help with packaging, but was hesitant to ask because on some sort of level, i felt like i was stomping on your toes a little

I think you will be shocked by the differences between wine-proaudio/linux-proaudio vs. othger alternatives... I need to get in touch with the FSThost maintainer too - i need him to start looking into supporting this stuff.

i want tier 1 windows VST/ASIO support on my h/W - these packages bring me about 85% of the way

capoeira wrote:

pro-audio user here (unfortuanatly no dev/programer/scripter)
one question: why no AUR-packages?

I actually talk about that in my OP. I am not good at that.... but it sounds like jhernberg is going to come to the rescue (possibly). I need to focus on more important things, such as enhancements, better gtk/wine integration - as well as cherry-picking a few more patches here and there.

Last edited by triplesquarednine (2012-12-31 21:50:30)

triplesquarednine · 2013-01-02 01:49:22

Just an update for those interests, more than one person (me) is now using L_ProAudio

I know of another Archer experimenting with L_PA-wine and i know someone in Ubuntuland running both kernel and wine - with success

FalkTX is making some test packages for the KxStudio crowd.

and i will be ready to drop new packages soon that have a couple of new patches, as well as some cleanups.

...and i have been flooded with Emails today about this _kickass_ project

happy happy joy joy

triplesquarednine · 2013-01-02 07:56:57

@ 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.

triplesquarednine · 2013-01-04 18:15:51

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)

Brett Lyons · 2013-01-04 21:52:16

You might be interested in :

https://lkml.org/lkml/2012/12/5/421
--
Also, the BFQ IO scheduler patch for the kernel. Homepage: http://algo.ing.unimo.it/people/paolo/disk_sched/

Last edited by Brett Lyons (2013-01-04 22:08:45)

triplesquarednine · 2013-01-04 22:02:16

Muse Research has now chipped in on helping sort out the patch work. (because of my initiative / networking and creation of L_pa!!! Linuxaudio users should take this as a BIG WIN for OUR community.

- I've documented each patch, what they do, what is applicable/not applicable to upstream / the how's and the why's (wine-devs also are aware and merging patches, investigating upstream problems, presented by others that may or may not be accepted. ~ ie: upstream wine will have improvements soon - L_pa-Wine will have less maintainance. ( i will be updating L_pa-Wine later )

I have also extended my hand (in friendship) to the project lead there, about trading tricks on taming linux-rt ~ so we will see what he says. (their 'secret sauce' in their product line is not things of that nature - they have finely crafted software + hardware to handle any and all VST quirks in their environment ~ which is a whole other ball game

but either way, things a looking up ...and i am still looking for people to collaberate on this project, help with Git / SF.net and whatever else. I also have some graphic art i am working for L_pa and icon-work for FSThost ~ both will take a little while, but i am motivated to improve Linuxaudio / L_pa and any other related project

FSThost author is also working on a host application, that will be of interest down the line.

- as well, i think i have a very practical way to get VSTs that don't properly accept (mapping) midi-program changes -> fxb/plugin presets. (and i don't thinking it's going to require much effort to get it working, being as most of the code applicable, is already implemented to work around the problem... i just need a bit more investigating

EDIT: Heard back from Muse Research's project lead: We are on friendly terms, and it's looking like i _may_ be included in their beta program...!!!

...looks like a week's worth of work (and a few years of experience) has paid off

Jordan

Last edited by triplesquarednine (2013-01-04 22:16:47)

triplesquarednine · 2013-01-04 22:24:07

@brett

Thank you for the 1st - going to look into it.

i'm already well aware of BFQ (and have chatted with it's dev, in the past) ~ i used to used that patchset (on Zen-Kernel + bfs) a couple of years ago, to combat RT being crappy on that H/W ~ with a bunch of hack, as well. ... those days were fun, and that 2.6.37 kernel was actually pretty sick (running in Fedora).

...man Oh man, am i making progress with my Project's goals (!!!)

EDIT: BUT! ...if this is something that you are interested in, there is nothing stoppping us from integrating it into L_pa ~ as it is an option / not a hard-requirement anyway.

I'll do some investigating (as i am not sure if BFQ works on RT). But i know _just_ whom to ask, from previous interraction with in the past; a guy involved with RT / CUDA development, whom i've gotten to know. ~ i'll see if he has anything useful to say on the matter, if not ~ i will hit the RT list.

but feel free to make a patch, i won't hesitate from dog-fooding it on my systems

... if it fails, it might yield useful info i can pass along to respective developers.

food for thought

Last edited by triplesquarednine (2013-01-05 00:17:14)

capoeira · 2013-01-05 00:55:41

triplesquarednine wrote:

I don't know how many people are following this thread

Be sure there are some.
I'll join the "testers" soon

triplesquarednine · 2013-01-05 02:22:21

@capoeira

good to know

and fyi, while the kernel isn't available in AUR, yet ~ Wine-L_pa is, rebased on 1.5.21 (just released upstream);

https://aur.archlinux.org/packages/wine-l-pa/

but remember, it doesn't play well with many windows DAWs yet, this has to do with limitations in wineASIO/wine-rt.. Use FSThost for the best handling of VST with L_pa, and (as i commented in AUR) ~ (when you start using this stuff) start testing old semi-working (but failing) VSTs ~ at my count locally, I have 19 VSTs working that _never_ worked quite right before. (!! and i haven't went through my directory really, nor hit KVRaudio)

with FSThost all prio/threading is handled ~ you should see great benefits, with none of the bottlenecks of Wine-rt.

...the DAW stuff will take time (this is new technology to us, and i have only been investigating the DAW problems over the last 2 days).

cheerz

triplesquarednine · 2013-01-05 03:06:59

Side-note: As general useful tip for (the odd) windows installer:

- every once in a while, there is a windows-installer that does not work (but the app and/or VST in fact, is well-supported).

it'll spit something like this (below), hang for a while and everntually fail)

[ninez@ninez ~]$ '/home/ninez/Downloads/ohm_studio_installer.exe' 
bash: /home/ninez/Downloads/ohm_studio_installer.exe: Permission denied
[ninez@ninez ~]$ chmod +x '/home/ninez/Downloads/ohm_studio_installer.exe' 
[ninez@ninez ~]$ '/home/ninez/Downloads/ohm_studio_installer.exe' 
fixme:exec:SHELL_execute flags ignored: 0x00000100

fixme:exec:SHELL_execute flags ignored: 0x00000100

the work around is simple;

- install the app using 'sudo' (to your *root* wine-prefix)

- open up 'regedit' (with sudo, again to use your root wine prefix), then search for the app/vsts related registry keys (right click and export/save).

- next you need to find all installed files and copy them into your ~/.wine prefix (or other used prefix).

- lastly, (without sudo) launch regedit; from the main menu 'import keys' ~ import the saved registry keys into regedit.

- close regedit and launch newly-installed application (make sure you have completely stopped wineserver and friends first. ~ wineboot is one such method)

I mention this, because i ran into it for the first time in a long time (yesterday) installing Ableton Live (for testing purposes, which jugged my memory - but obviously OHM studio is another _fine_ example).

but have been aware of this hack, for a few years now.

~ ideally, we should have some mechanism in L_pa to handle these kinds of quirks (as it would make things easier, for those troublesome apps).

~ i haven't looked into this at all yet (implementing it). but go nuts, if you come up with something that works, we can look at adding it to L_pa

Jordan

Last edited by triplesquarednine (2013-01-05 03:09:28)

triplesquarednine · 2013-01-05 05:50:59

Just for Jun;

FSTHost + L_pa --> FL Studio ~ VST plugin (latest demo / release).

it actually just gave me an idea that i need to run by FSThost/Pawel (that could improve some handling for users).

FL Studio runs very well here, although realistically, i should be giving the app a little more buffering, if i was working on a track. FL doesn't cause xruns until 60-70% DSP load in jack (on my machine), which are very few (if even audible) @ 99% you get some grains/distortions (from me not feeding the DAW enough buffers from jack, in the first place..).

At 88.2/96khz on this box, i would probably (in a real life situation, making music in FL), be using 512 vs. 256 buffer to give everything a larger slice of time to process.

it's interesting to see this DAW being hosted with FSThost, anyway.

triplesquarednine · 2013-01-05 06:09:21

oh and i meant to post the output from that run.

You'll notice that FSThost handles the threading/priorities quite nicely ~ and if you are familiar with FSThost, but not using L_pa ~ you have never seen any VST have threading like this; http://pastebin.com/SxPMNp9X

If you are familiar with Windows priorities, you can clearly see them being mapped to linux priorites. for example;

JACK: JACK: Thread 7106 at THREAD_PRIORITY_TIME_CRITICAL set to SCHED_FIFO - priority 20
Thread 7107 at THREAD_PRIORITY_TIME_CRITICAL set to SCHED_FIFO - priority 20
JACK: Setting thread 7106 at level THREAD_PRIORITY_NORMAL to SCHED_NORMAL
Setting thread 7107 at level THREAD_PRIORITY_NORMAL to SCHED_NORMAL
JACK: JACK: Thread 7106 at THREAD_PRIORITY_TIME_CRITICAL set to SCHED_FIFO - priority 20
Thread 7107 at THREAD_PRIORITY_TIME_CRITICAL set to SCHED_FIFO - priority 20
JACK: Setting thread 7106 at level THREAD_PRIORITY_NORMAL to SCHED_NORMAL

each thread is being directed as to how it should be handled in Linux land.

happy stuff

triplesquarednine · 2013-01-05 09:30:53

I've got a new linux-l-pa pkgbuild on SF.net for people to try;

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

please test

notes/changes:

- it does NOT install over linux-rt

- it is a *unique package*.- no nvidia-l-pa package yet (-rt patched for binary beta driver) and i'll do that today/tonight... so if using the blob (like me); you are on your own, until i sort that out.

- i have reverted/ditched a few patches (other than for my local machines) because of user issues.- I've also commented out the last applied patch for reasons, that i've stated above, and because it's a performance hack, that some people may not be comfortable with...

I think in my excitement and busyiness, i really hadn't put enough thought into that one. That being said, the revert-stable-write-page.patch yields very nice performance improvements in general and fixes some latency bottlenecks with wine (particularly, squashing certain nasty latencies in ext4 operations cause ridiculous amounts for latency (in particular for L_pa-Wine, since it is quite a bit quicker/heavy duty than normal Wine)

...So this becomes a question of sacrificing a little data-integrity vs. a nice performance boost / more stable / uninterrupted operation. ~ Particularly, i am finding with Wine, since it is actually a power-house now...

* I should also note that i have been reverting 'stable write pages' in ext4 for _all_ of the 3.0+ linux-rt series in order to get the performance required... Sooo, make your own decisions as what you want to do - but i have left the patch in the pkgbuild for those whom may need it, since it has been very critical for my systems... There is also new prepatched-sources on Sf.net (or will be shortly). - for the next release I have 2, possibly three new patches... it'll be up in a few dayz

* as a side note:L_pa-Wine breaks DOSBOX support in Wine. my advice; go download DOSBOX, instead if you are all about dos ~ L_pa-Wine isn't for dos games

Last edited by triplesquarednine (2013-01-05 11:39:50)

capoeira · 2013-01-05 11:03:25

triplesquarednine wrote:

Wine-L_pa is, rebased on 1.5.21 (just released upstream);
https://aur.archlinux.org/packages/wine-l-pa/

nice, just installed this.

triplesquarednine · 2013-01-05 11:35:12

sweet.

Let me know how it goes, read the readme and wiki.

...grab the latest FSThost code from svn (since it uses Wine-L_pa effectively).

cheerz

capoeira · 2013-01-05 12:33:01

triplesquarednine wrote:

sweet.
Let me know how it goes, read the readme and wiki.
...grab the latest FSThost code from svn (since it uses Wine-L_pa effectively).
cheerz

not now, but soon I'll test all this

triplesquarednine · 2013-01-05 23:47:13

i need help with nvidia-l-pa packaging and quite frankly, i do not have the time to be learning about packaging in Archlinux right now (I'm not even all that interested in being a package maintatiner, really). especially when someone who already knows this stuff could have it done in a minute or two;

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

it's just screwing up on integrity checks (can install with --skipinteg and works with linux-l-pa locally - tested). but i am busy investigating ext4 in 3.8 kernel and this is how my time should be spent right now (resolving ext4 problems, generically, for later relase of L_pa 3.8-rt) and/or working on my Wiki pages and other bits - to be focusing on packaging.

~ ie: I _HATE_ writing/working on pkgbuilds (just so you guys know.. lol)

so technically, by going to sf.net Nvidia-rt users _should_ be able to use linux-l-pa with the latest beta 313.09 driver (makepkg -si --skipinteg). Anyway, I am am done with packaging for today ~ i don't know when i will get to it, but won't upload linx-l-pa until i have a working nvidia-l-pa for people to use..so if ppl want this stuff in AUR ~ please help.

jordan

Last edited by triplesquarednine (2013-01-06 01:51:27)

arkay · 2013-01-06 02:33:27

I'll just pop in to say that I am also watching this very closely.

I just don't have the free cycles to play re alpha/beta testing at the moment but I certainly appreciate the work effort that will result in an easy to install fantastically useful compatibility stack for Linux Pro Audio. When things solidify I'll certainly be installing and checking things out.

It really would be fantastic to have a Muse like level of stability and large choice of available VST's on an Arch build!!

Keep up the great work!

Cheers,

Arkay.

Last edited by arkay (2013-01-06 02:54:28)

triplesquarednine · 2013-01-06 03:37:51

I had some stuff i wanted people to try out here, but I have to do some investigating aka: not ready.

Last edited by triplesquarednine (2013-01-06 04:17:36)

triplesquarednine · 2013-01-06 03:41:24

scratch that... /

got confused on something there...

I think i re-enabled wine-rt in a compile by accident or / something is strange is happening here...

dumb dumb dumb.

desperately want to get wineASIO sorted quickly though.

Last edited by triplesquarednine (2013-01-06 04:10:46)

triplesquarednine · 2013-01-06 04:16:28

arkay wrote:

I'll just pop in to say that I am also watching this very closely.

I actually appreciate that. I kinda feel like i am talking to myself most of the time. lol.

arkay wrote:

I just don't have the free cycles to play re alpha/beta testing at the moment but I certainly appreciate the work effort that will result in an easy to install fantastically useful compatibility stack for Linux Pro Audio. When things solidify I'll certainly be installing and checking things out.

well, definitely aimed at improving a few components and having some patches merged upstream anyway

arkay wrote:

It really would be fantastic to have a Muse like level of stability and large choice of available VST's on an Arch build!!

It would be hard to obtain quite the level of love that Muse' puts into it's host. But I am definitely all about improving all of our stack, where we can. Having a good implementation of wine and some apps that support it goes a _long_ way, though.

arkay wrote:

Keep up the great work!.

thanks man. I do what i can, when i can.

Last edited by triplesquarednine (2013-01-06 04:20:33)

superprick · 2013-01-06 18:36:06

Ok i finally got registered with this forum. For anyone else reading and having problems with the arch Captcha questionn what is the output of ? If the clock on your desktop is in local time and not utc.. you have to change the first part by inserving V where the W is date -u +%V$ not date -u +%W$

I do have a question. You mention problems with your kernel and Nvidia that you are sorting out. If i am Running amd Catalyst proprietary should i have the same concerns.

Stupid question 2. I understand the reasons for tweaking the kernal and Wine to work together with audio apps. But i think this may only be one link in the chain. Correct me if i am wrong but doesnt Receptor run a vst host that is a windows program running in wine. It appears that most of us have the best luck running VST's inside of a host designed for windows. Why not Create a vst Host specifically for linux that runs inside of wine and is optimized from source to run in wine. And as far as Wineasio problems. couldnt something like jack2's Netjack be used to connect the in and out streams from the vst to jack on the linux host.

I have yet to start using win vst on my linux boxes. Having some issues getting it running in arch/ was pretty much plug and play in KXstudio (thank you faltx) I do use ardour as my daw. but i am using a winbows machine loaded with jack2/netjack to host my vst. and send them back to ardour. on a gigabit network i see added latency of about 1 ms. maybe using the virtual network switch that is in place for virtual machines somehow could eliminate half of this because it probably comes from my network switch.

I may be totally off my rocker. Like i said in another forum. Im not a coder Just a guy that builds networks and KVM server farms for people

Arch Linux

#1 2012-12-31 20:51:03

L_Proaudio Project: Wine-L_pa + Linux-L_pa

#2 2012-12-31 21:18:03

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

#3 2012-12-31 21:38:18

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

#4 2012-12-31 21:47:49

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

#5 2013-01-02 01:49:22

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

#6 2013-01-02 07:56:57

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

#7 2013-01-04 18:15:51

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

#8 2013-01-04 21:52:16

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

#9 2013-01-04 22:02:16

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

#10 2013-01-04 22:24:07

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

#11 2013-01-05 00:55:41

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

#12 2013-01-05 02:22:21

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

#13 2013-01-05 03:06:59

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

#14 2013-01-05 05:50:59

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

#15 2013-01-05 06:09:21

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

#16 2013-01-05 09:30:53

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

#17 2013-01-05 11:03:25

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

#18 2013-01-05 11:35:12

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

#19 2013-01-05 12:33:01

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

#20 2013-01-05 23:47:13

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

#21 2013-01-06 02:33:27

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

#22 2013-01-06 03:37:51

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

#23 2013-01-06 03:41:24

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

#24 2013-01-06 04:16:28

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

#25 2013-01-06 18:36:06

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

Board footer