I made following observation (Lucid Lynx, and I compiled Jack2 myself):
With wineasio 0.9.0 is it impossible to run Pianoteq (Windows version) below 512 frames/period. When I try lower values, Pianoteq crashes during startup.
Jack2 reports this:
JackPosixSemaphore::TimedWait err = Connection timed out
JackFreewheelDriver::ProcessSync SuspendRefNum error
JackAudioDriver::ProcessGraphSync: ProcessSlaves error, engine may now behave abnormally!!
JackAudioDriver::ProcessSync: process error, skip cycle…
Cannot connect ports owned by inactive clients: "Pianoteq" is not active
Cannot connect ports owned by inactive clients: "Pianoteq" is not active
Cannot connect ports owned by inactive clients: "Pianoteq" is not active
Cannot connect ports owned by inactive clients: "Pianoteq" is not active
Here also a part of the asio trace:
trace:asio:Start iface: 0x1399e0
trace:asio:Start Runnning simple BufferSwitch() callback
trace:asio:jack_thread_creator arg: 0x7d20f6c8, thread_id: 0x7d20f6dc, attr: 0x32f0cc, function: 0x7d80adec
trace:asio:DllMain hInstDLL: 0x7d860000, fdwReason: 2 lpvReserved: (nil))
trace:asio:jack_thread_creator_helper arg: 0x7d20f6c8
warn:asio:Start Unable to connect system:capture_1 to Pianoteq:in_1
warn:asio:Start Unable to connect system:capture_2 to Pianoteq:in_2
warn:asio:Start Unable to connect to Pianoteq:out_1
warn:asio:Start Unable to connect to Pianoteq:out_2
trace:asio:Start WineASIO successfully loaded
trace:asio:DllMain hInstDLL: 0x7d860000, fdwReason: 2 lpvReserved: (nil))
trace:asio:DllMain hInstDLL: 0x7d860000, fdwReason: 2 lpvReserved: (nil))
trace:asio:DllMain hInstDLL: 0x7d860000, fdwReason: 2 lpvReserved: (nil))
With wineasio 0.8.0 I can go down to 64 frames/period, and I do not get xruns. This is as good as when I use the native Linux version of Pianoteq together with jack2. I also have no problems wich Jack1 and wineasio 0.9.0. This problem seems to occur only in the combination of jack2 together with wineasio 0.9.0
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I can confirm this bug. Don't know what the solution is though and have very little time right now and don't know hardly anything about the internals of JACK2. I suspect that the problem lies with JACK2, since JACK1 works and JACK2 works at certain buffer sizes. Can you run jackd with the -v flag, and attach the server and client outputs to a msg in the jack-dev mailing list. Probably the best way to get someone to have a look at it. I am also using x86_64, but normally run with JACK1.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ok, I will do this. Perhaps you are interested in a detailed analysis with two different sound cards and both jack versions. I always played back the same MIDI file in Pianoteq (win32, Lucid Lynx amd64):
Internal sound card "HDA Intel"
unusable below 512 periods. With wineasio 0.9.0 (Jack 2) no sound and error messages from jack, with wineasio 0.9.0 (Jack 1) or wineasio 0.8.0 (both jack versions) xruns with cracklings.
USB sound card "Audio Kontrol 1" (Native Instruments)
Jack 2 (1.9.7, synchronous mode)
wineasio 0.9.0: 1024 periods no xruns, below this no sound and error messages from jack
wineasio 0.8.0: 64 periods no xruns,
Jack 1 (0.118.0)
similar results with wineasio 0.8.0 and 0.9.0. In both cases xruns with 256 periods, mostly without cracklings. Many xruns with 128 periods and below. With 512 periods no xruns
Here you can see that for me the best scenario is currently the combination of Jack2 together with Wineasio 0.8.0.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Heh, looks like I was wrong :) Think I found the bug in wineasio. If you can, please try to get the code from the git repo: git://wineasio.git.sourceforge.net/gitroot/wineasio/wineasio If you don't know how to use git, just install it, and cd to where you keep your source code and do: git clone git://wineasio.git.sourceforge.net/gitroot/wineasio/wineasio
Hopefully this will fix the JACK2 problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I suppose you could also just use the normal git. change to the right dir and do git pull. I suppose eclipse will see the new source code when you open a prj.
Happy to hear that it fixed the problem though.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you! Your last correction solves the wineasio / Jack2 problem.
However, I have a general question: When I use a native Linux application with Jack1/Jack2, I can activate SMP (e.g. "multicore rendering" in Pianoteq) to distribute the CPU load to more than one single core. With a Windows audio application and wineasio (I already tried Kontakt Player, Reaper and Pianoteq Win32 version) this is not possible (many xruns). Is this simply not possible with Wine (1.2) yet, or does wineasio not support it?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hmm, wine is relatively inefficient. I do use reaper in wine myself and multicore works fine (1.3.x, but afaik 1.2.x works too). but unfortunately too high a workload and low latency does mean that I get some xruns. There is a big design limit in wine due to many system calls passing through the wineserver component which is single threaded and passes through a socket. Graphics are relatively inefficient too.
That being said i downloaded a demo of pianoteq and tried it, i managed to run it in auto pessimistic mode with jack1 (from svn) at 128 samples buffer with no xruns, but then polyphony just went to some 20-30 voices or so :(
One patch that might help a little is my wine-rt patch that allows win programs to set higher priorities (read sched_fifo) under wine/linux, you can find it at: http://dl.dropbox.com/u/879835/wine-rt-101107.patch
I guess the only solution for this problem is either a redesign of the wineserver (which seems unlikely), faster hardware, or possibly that Modartt tests pianoteq in wine/wineasio and possibly come up with a better way to synchronize threads or whatever the problem is. Maybe it's just not possible with the present wine code. You could also possibly try cedega (a commercial fork of wine) which afaik has redesigned the wineserver as they perceived it as a bottle neck. Have never tried cedega and don't know if it's possible to run wineasio with it…
In conclusion I can only say that I find it amazing that it works as well as it does to run windows audio software under linux, but that if a native linux port exists, then it's clearly the superior choice :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the information. I only had the suspicion that Wine has a design limitation. For me it is ok that I cannot activate SMP support in Wine for low latency audio.
When I run the Win32 version of Pianoteq under Wine, I only do this for testing. Normally I am using the native Linux version. I have another scenario where I need to run a Windows audio application: Sometimes I split the keyboard to play an electric bass with the left hand and a piano with the right hand. Here I run Kontakt Player (bass, single core) under Wine with Wineasio together with Pianoteq (piano, multi core) with Jack. It is really cool that this is working on my 3 year old notebook (256 frames/period, Core 2 Duo, 1,67 GHz).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You should be able to use multicore. If you do use wineasio I would recomment building wine with my wine-rt patch, alternatively if you are using a ubuntu/debian linux, add the kxstudio repos: http://kxstudio.sourceforge.net/mediawiki/index.php/Main_Page
It will help with running wine apps at low latency even if it's not a cure all.
Try starting with a command like similar to: schedtool -F -p 54 -e env WINE_RT=55 WINE_SRV_RT=56 wine ~/.wine/drive_c/Program\ Files/Modartt/Pianoteq/Pianoteq.exe
The values for priority might need some experimentation…I seem to be able to run at 128 samples with jack1 and audo pessimistic mode with hardly any xrun unless i'm pressing 30 keys at once with my forearm :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually I seem to get the best result when disabling multicore in Pianoteq. If not I see the performance meter rising slowly when banging willdly on the keys until it overloads, I speculate that this is an artifact of using windows functions to sync the 2 threads. Also the wine-rt patch or starting it with schedtool seems to have no discernible effect.
So about the best result I've achieved is on my Intel Q6600 cpu with jack1 at 128 samples, wineasio 0.9.0, a vanilla wine and disabling multicore, ployphony set to 256. I get a performance index of 42, (in linux 46), and I can play all day hitting maybe 30-40 voices. I can overloaded it when I press the sustain pedal and bang as a wild one on the keys making noise, happens somewhere over 100 voices. But I can actually do the same when running the native linux version with multicore enabled. CPU usage seems very similar too, so I think one can say that the wine version runs equally well with wineasio as the native linux one, the only caveat being that multicore needs to be disabled.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I made following observation (Lucid Lynx, and I compiled Jack2 myself):
With wineasio 0.9.0 is it impossible to run Pianoteq (Windows version) below 512 frames/period. When I try lower values, Pianoteq crashes during startup.
Jack2 reports this:
JackPosixSemaphore::TimedWait err = Connection timed out
JackFreewheelDriver::ProcessSync SuspendRefNum error
JackAudioDriver::ProcessGraphSync: ProcessSlaves error, engine may now behave abnormally!!
JackAudioDriver::ProcessSync: process error, skip cycle…
Cannot connect ports owned by inactive clients: "Pianoteq" is not active
Cannot connect ports owned by inactive clients: "Pianoteq" is not active
Cannot connect ports owned by inactive clients: "Pianoteq" is not active
Cannot connect ports owned by inactive clients: "Pianoteq" is not active
Here also a part of the asio trace:
trace:asio:Start iface: 0x1399e0
trace:asio:Start Runnning simple BufferSwitch() callback
trace:asio:jack_thread_creator arg: 0x7d20f6c8, thread_id: 0x7d20f6dc, attr: 0x32f0cc, function: 0x7d80adec
trace:asio:DllMain hInstDLL: 0x7d860000, fdwReason: 2 lpvReserved: (nil))
trace:asio:jack_thread_creator_helper arg: 0x7d20f6c8
warn:asio:Start Unable to connect system:capture_1 to Pianoteq:in_1
warn:asio:Start Unable to connect system:capture_2 to Pianoteq:in_2
warn:asio:Start Unable to connect to Pianoteq:out_1
warn:asio:Start Unable to connect to Pianoteq:out_2
trace:asio:Start WineASIO successfully loaded
trace:asio:DllMain hInstDLL: 0x7d860000, fdwReason: 2 lpvReserved: (nil))
trace:asio:DllMain hInstDLL: 0x7d860000, fdwReason: 2 lpvReserved: (nil))
trace:asio:DllMain hInstDLL: 0x7d860000, fdwReason: 2 lpvReserved: (nil))
With wineasio 0.8.0 I can go down to 64 frames/period, and I do not get xruns. This is as good as when I use the native Linux version of Pianoteq together with jack2. I also have no problems wich Jack1 and wineasio 0.9.0. This problem seems to occur only in the combination of jack2 together with wineasio 0.9.0
I forgot to mention that I use amd64.
I can confirm this bug. Don't know what the solution is though and have very little time right now and don't know hardly anything about the internals of JACK2. I suspect that the problem lies with JACK2, since JACK1 works and JACK2 works at certain buffer sizes. Can you run jackd with the -v flag, and attach the server and client outputs to a msg in the jack-dev mailing list. Probably the best way to get someone to have a look at it. I am also using x86_64, but normally run with JACK1.
ok, I will do this. Perhaps you are interested in a detailed analysis with two different sound cards and both jack versions. I always played back the same MIDI file in Pianoteq (win32, Lucid Lynx amd64):
Internal sound card "HDA Intel"
unusable below 512 periods. With wineasio 0.9.0 (Jack 2) no sound and error messages from jack, with wineasio 0.9.0 (Jack 1) or wineasio 0.8.0 (both jack versions) xruns with cracklings.
USB sound card "Audio Kontrol 1" (Native Instruments)
Jack 2 (1.9.7, synchronous mode)
wineasio 0.9.0: 1024 periods no xruns, below this no sound and error messages from jack
wineasio 0.8.0: 64 periods no xruns,
Jack 1 (0.118.0)
similar results with wineasio 0.8.0 and 0.9.0. In both cases xruns with 256 periods, mostly without cracklings. Many xruns with 128 periods and below. With 512 periods no xruns
Here you can see that for me the best scenario is currently the combination of Jack2 together with Wineasio 0.8.0.
Sorry, I meant "frames/period", not "periods" in my last posting.
Heh, looks like I was wrong :) Think I found the bug in wineasio. If you can, please try to get the code from the git repo: git://wineasio.git.sourceforge.net/gitroot/wineasio/wineasio If you don't know how to use git, just install it, and cd to where you keep your source code and do: git clone git://wineasio.git.sourceforge.net/gitroot/wineasio/wineasio
Hopefully this will fix the JACK2 problem.
Reaper is now happy. I'll have to get a JACK SVN built on my linux box so I can play with it properly, though.
I suppose you could also just use the normal git. change to the right dir and do git pull. I suppose eclipse will see the new source code when you open a prj.
Happy to hear that it fixed the problem though.
Thank you! Your last correction solves the wineasio / Jack2 problem.
However, I have a general question: When I use a native Linux application with Jack1/Jack2, I can activate SMP (e.g. "multicore rendering" in Pianoteq) to distribute the CPU load to more than one single core. With a Windows audio application and wineasio (I already tried Kontakt Player, Reaper and Pianoteq Win32 version) this is not possible (many xruns). Is this simply not possible with Wine (1.2) yet, or does wineasio not support it?
Hmm, wine is relatively inefficient. I do use reaper in wine myself and multicore works fine (1.3.x, but afaik 1.2.x works too). but unfortunately too high a workload and low latency does mean that I get some xruns. There is a big design limit in wine due to many system calls passing through the wineserver component which is single threaded and passes through a socket. Graphics are relatively inefficient too.
That being said i downloaded a demo of pianoteq and tried it, i managed to run it in auto pessimistic mode with jack1 (from svn) at 128 samples buffer with no xruns, but then polyphony just went to some 20-30 voices or so :(
One patch that might help a little is my wine-rt patch that allows win programs to set higher priorities (read sched_fifo) under wine/linux, you can find it at: http://dl.dropbox.com/u/879835/wine-rt-101107.patch
I guess the only solution for this problem is either a redesign of the wineserver (which seems unlikely), faster hardware, or possibly that Modartt tests pianoteq in wine/wineasio and possibly come up with a better way to synchronize threads or whatever the problem is. Maybe it's just not possible with the present wine code. You could also possibly try cedega (a commercial fork of wine) which afaik has redesigned the wineserver as they perceived it as a bottle neck. Have never tried cedega and don't know if it's possible to run wineasio with it…
In conclusion I can only say that I find it amazing that it works as well as it does to run windows audio software under linux, but that if a native linux port exists, then it's clearly the superior choice :)
Thanks for the information. I only had the suspicion that Wine has a design limitation. For me it is ok that I cannot activate SMP support in Wine for low latency audio.
When I run the Win32 version of Pianoteq under Wine, I only do this for testing. Normally I am using the native Linux version. I have another scenario where I need to run a Windows audio application: Sometimes I split the keyboard to play an electric bass with the left hand and a piano with the right hand. Here I run Kontakt Player (bass, single core) under Wine with Wineasio together with Pianoteq (piano, multi core) with Jack. It is really cool that this is working on my 3 year old notebook (256 frames/period, Core 2 Duo, 1,67 GHz).
You should be able to use multicore. If you do use wineasio I would recomment building wine with my wine-rt patch, alternatively if you are using a ubuntu/debian linux, add the kxstudio repos: http://kxstudio.sourceforge.net/mediawiki/index.php/Main_Page
It will help with running wine apps at low latency even if it's not a cure all.
Try starting with a command like similar to: schedtool -F -p 54 -e env WINE_RT=55 WINE_SRV_RT=56 wine ~/.wine/drive_c/Program\ Files/Modartt/Pianoteq/Pianoteq.exe
The values for priority might need some experimentation…I seem to be able to run at 128 samples with jack1 and audo pessimistic mode with hardly any xrun unless i'm pressing 30 keys at once with my forearm :)
Actually I seem to get the best result when disabling multicore in Pianoteq. If not I see the performance meter rising slowly when banging willdly on the keys until it overloads, I speculate that this is an artifact of using windows functions to sync the 2 threads. Also the wine-rt patch or starting it with schedtool seems to have no discernible effect.
So about the best result I've achieved is on my Intel Q6600 cpu with jack1 at 128 samples, wineasio 0.9.0, a vanilla wine and disabling multicore, ployphony set to 256. I get a performance index of 42, (in linux 46), and I can play all day hitting maybe 30-40 voices. I can overloaded it when I press the sustain pedal and bang as a wild one on the keys making noise, happens somewhere over 100 voices. But I can actually do the same when running the native linux version with multicore enabled. CPU usage seems very similar too, so I think one can say that the wine version runs equally well with wineasio as the native linux one, the only caveat being that multicore needs to be disabled.
512 samples in Linux seems faster than 512 samples in Windows…
like 2ghz Intel faster than 2ghz G4
since i cant use the same software… who knows…
but with VSTHost DP 512 feels like 128.
it's also a kernel thing…
512 with Generic Kernel 3.0.0.8
KXStudio 10.04 with TangoStudio1.1 RT Kernel Jack can go faster…
rme hdsp9632
alsa drivers