2 Nov
2010
2 Nov
'10
5:53 p.m.
Hi list,
I am seeing what appears to be a 4 - 7 usec context switch time on a 3
GHz Core 2 Duo machine with the 2.6 kernel, and 10 - 15 usecs on a 1.66
GHz Atom. Is that reasonable? Does anyone have any tips on how to speed
that up, if possible?
The background is that I have two apps --- one a straight Linux app and
the other a Wine one. The Linux app is doing the mixing and the Wine app
is hosting Windows VSTs.
During audio processing I use a sem_t to signal from the mixer app to
the vst app. Once the vst app is done processing, it signals back to the
mixer app over another sem_t.
I believe this is roughly the approach taken by other linux audio apps
to host Wine vsts. And is also something like how Jack does IPC.
But it takes about 4-7 usecs on the faster machine to signal another app
and have it wake up again. I assume this is the time needed for a
context switch.
Since this has to happen twice per buffer, at a 32 sample buffer size
and with 10 VSTs, overhead accounts for about 14% of the CPU. On the
slower Atom machine, it would account for 33% of the CPU.
Any hints on how to reduce that time, or an alternate IPC design to look
in to?
Thanks for any help,
Michael Ost
Muse Research, Inc.
2 Nov
2 Nov
6:07 p.m.
On Tue, Nov 2, 2010 at 12:53 PM, Michael Ost <most(a)museresearch.com> wrote:
Hi list,
I am seeing what appears to be a 4 - 7 usec context switch time on a 3 GHz
Core 2 Duo machine with the 2.6 kernel, and 10 - 15 usecs on a 1.66 GHz
Atom. Is that reasonable? Does anyone have any tips on how to speed that up,
if possible?
context switch time is a combination of:
(a) instructions executed to implement the switch
(b) processor stalling after the switch due to TLB invalidation (the virtual
address mapping has changed)
you can't easily measure (b) but its value depends in part on the
working set size of the tasks on each side of the switch.
(a) is going to be directly linear with the processor Hz, and so your
results, which show that a processor which is roughly half the speed
takes roughly twice as a long is entirely expected.
I believe this is roughly the approach taken by other
linux audio apps to
host Wine vsts. And is also something like how Jack does IPC.
well, yes and no. Its similar to the approach used by dssi-vst and
kjetil's original vstserver. its not how FST works.
But it takes about 4-7 usecs on the faster machine to
signal another app and
have it wake up again. I assume this is the time needed for a context
switch.
Since this has to happen twice per buffer, at a 32 sample buffer size and
with 10 VSTs, overhead accounts for about 14% of the CPU. On the slower Atom
machine, it would account for 33% of the CPU.
you can't reduce context switch times. the code involved is in the kernel.
it is precisely this problem that led to FST, and the more general use
of FST by ardour (for example) where rather than going back and forth
between wine and the linux app, the linux app becomes a wine process
itself, and everything is in-process.
6:17 p.m.
Paul Davis wrote:
Ah, so no magic bullet then! %) This makes sense. Thanks for your response.
- Michael Ost
On Tue, Nov 2, 2010 at 12:53 PM, Michael Ost
<most(a)museresearch.com> wrote:
> Hi list,
>
> I am seeing what appears to be a 4 - 7 usec context switch time on a 3 GHz
> Core 2 Duo machine with the 2.6 kernel, and 10 - 15 usecs on a 1.66 GHz
> Atom. Is that reasonable? Does anyone have any tips on how to speed that up,
> if possible?
<snip>
Since this has
to happen twice per buffer, at a 32 sample buffer size and
with 10 VSTs, overhead accounts for about 14% of the CPU. On the slower Atom
machine, it would account for 33% of the CPU.
you can't reduce context switch times. the code involved is in the kernel.
it is precisely this problem that led to FST, and the more general use
of FST by ardour (for example) where rather than going back and forth
between wine and the linux app, the linux app becomes a wine process
itself, and everything is in-process. 
6:45 p.m.
On Tue, Nov 02, 2010 at 10:17:30AM -0700, Michael Ost wrote:
Ah, so no magic bullet then! %) This makes sense.
Thanks for your response.
One thing to look at is if you really need all those context switches.
That would be the case only if all the VST plugins are in series and
there is some linux code between each one and the next.
One way to organise the processing on both sides is to continue
in the same process until it depends on results from the other.
This will reduce the number of context switches in almost all
cases.
And 32 frames is quite small - there may be reasons for that
but in many cases you can use larger period sizes.
Ciao,
--
FA
There are three of them, and Alleline.
7:02 p.m.
fons(a)kokkinizita.net wrote:
On Tue, Nov 02, 2010 at 10:17:30AM -0700, Michael Ost
wrote:
Right, that's an option.
Ah, so no magic bullet then! %) This makes sense.
Thanks for your response.
One thing to look at is if you really need all those context switches.
That would be the case only if all the VST plugins are in series and
there is some linux code between each one and the next.
One way to organise the processing on both sides is to continue
in the same process until it depends on results from the other.
This will reduce the number of context switches in almost all
cases. And 32 frames is quite small - there may be reasons
for that
but in many cases you can use larger period sizes.
Low latency is part of the "spec battle" that our product is engaged in.
I think I need to look for an option that doesn't use IPC during processing.
Thanks,
- Michael Ost
10 Nov
10 Nov
7:15 p.m.
On 11/2/10 10:06 AM, Paul Davis wrote:
I asked Alexandre Julliard, the maintainer of the Wine project, about
the libfst approach, and thought this list might be interested in his
response.
- Michael Ost
First message (nov 8) when asked for a read on the libfst design he
said, "They have a wineserver and everything, they just bypass the
preloader and initial setup. It's a variant of the Mono patch. It should
work OK as long as both the host Linux app and the Windows DLL are
well-behaved and don't depend on things like memory layout, switching
stacks, signals, starting Linux threads, etc."
And here's the second message, an exchange where I (MO) asked him (AJ)
for details about the above points:
MO: "Memory layout" - is there any risk that a DLL might see a smaller
VM size without the preloader? We are using the /3GB switch. Would that
be at risk?
AJ: It's not just size, but areas that are expected to be free that
would be occupied, for instance the DLL load address, things like that.
MO: "Switching stacks" - I can't see an audio DLL switching stacks.
Sounds like something a debugger might do...?
AJ: I know the jack library on Linux plays some strange games with the
stack to try to reduce latency. I'd imagine an audio DLL might try to do
stuff like that.
MO: "Signals" - seems very unlikely for a hosted audio DLL
"Starting Linux threads" - shouldn't happen from straight windows code.
AJ: These two would be potential problems in the Linux host application,
not in the DLL.
MO: "Etc" - and what might this be? %)
AJ: I'm sure there are other things, it's really hard to predict what
unspecified code is going to do. Basically everything we do during
startup was added because something depended on it, so anything that is
bypassed is a potential problem. Whether it will be a problem in actual
use can really only be determined by testing.
MO: This is all in WINE/loader, right?
AJ: Yes, but there's a lot of init code in ntdll too, particularly
regarding memory layout (that code will still be executed with the
libfst patch, but it may not be able to set things up the way it wants
to when not run at process startup).
On Tue, Nov 2, 2010 at 12:53 PM, Michael
Ost<most(a)museresearch.com> wrote:
> Hi list,
>
> I am seeing what appears to be a 4 - 7 usec context switch time on a 3 GHz
> Core 2 Duo machine with the 2.6 kernel, and 10 - 15 usecs on a 1.66 GHz
> Atom. Is that reasonable? Does anyone have any tips on how to speed that up,
> if possible?
<snip>
Since this has
to happen twice per buffer, at a 32 sample buffer size and
with 10 VSTs, overhead accounts for about 14% of the CPU. On the slower Atom
machine, it would account for 33% of the CPU.
you can't reduce context switch times. the code involved is in the kernel.
it is precisely this problem that led to FST, and the more general use
of FST by ardour (for example) where rather than going back and forth
between wine and the linux app, the linux app becomes a wine process
itself, and everything is in-process.
7:39 p.m.
On Wed, Nov 10, 2010 at 1:15 PM, Michael Ost <most(a)museresearch.com> wrote:
I asked Alexandre Julliard, the maintainer of the Wine
project, about the
libfst approach, and thought this list might be interested in his response.
- Michael Ost
First message (nov 8) when asked for a read on the libfst design he said,
"They have a wineserver and everything, they just bypass the preloader and
initial setup. It's a variant of the Mono patch. It should work OK as long
as both the host Linux app and the Windows DLL are well-behaved and don't
depend on things like memory layout, switching stacks, signals, starting
Linux threads, etc."
The problem is that this is wrong. Alexandre is remembering stuff from
long, long ago.
the FST approach now involves absolutely no wine hacks at all.
7:44 p.m.
On Wed, Nov 10, 2010 at 1:39 PM, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
On Wed, Nov 10, 2010 at 1:15 PM, Michael Ost
<most(a)museresearch.com> wrote:
to expand just a little, the libfst approach involves just a couple of
components, most easily explained by using ardour as an example:
* use gcc to compile ardour as shared library, not as an
executable. be sure to include an entry point and do not include main
* use gcc to compile libfst which is the windows/linux hybrid code
that actually supports VST loading, and provides a C-based API for
an app using it
* use winegcc compile a tiny stub windows progam that does nothing
but call the entry point defined in step 1
* link it all together using winegcc
result: a wine app that does all the usual wine stuff at startup, and
then jumps into the entry point of "ardour". when it loads VSTs it
does so via the libfst API.
this is an ordinary wine app, except that 99.9% of its code is
actually a big linux shared library.
jfst (the JACK VST client) is based on the same idea, although its not
quite as blatantly obvious what is going on, since you can't build it
any other way.
--p
I asked Alexandre Julliard, the maintainer of the
Wine project, about the
libfst approach, and thought this list might be interested in his response.
- Michael Ost
First message (nov 8) when asked for a read on the libfst design he said,
"They have a wineserver and everything, they just bypass the preloader and
initial setup. It's a variant of the Mono patch. It should work OK as long
as both the host Linux app and the Windows DLL are well-behaved and don't
depend on things like memory layout, switching stacks, signals, starting
Linux threads, etc."
The problem is that this is wrong. Alexandre is remembering stuff from
long, long ago.
the FST approach now involves absolutely no wine hacks at all.
7:51 p.m.
Paul Davis wrote:
On Wed, Nov 10, 2010 at 1:39 PM, Paul Davis
<paul(a)linuxaudiosystems.com> wrote:
So, it becomes a winelib app then. Thanks for the clarification.
- Michael Ost
On Wed, Nov 10, 2010 at 1:15 PM, Michael Ost
<most(a)museresearch.com> wrote:
to expand just a little, the libfst approach involves just a couple of
components, most easily explained by using ardour as an example:
* use gcc to compile ardour as shared library, not as an
executable. be sure to include an entry point and do not include main
* use gcc to compile libfst which is the windows/linux hybrid code
that actually supports VST loading, and provides a C-based API for
an app using it
* use winegcc compile a tiny stub windows progam that does nothing
but call the entry point defined in step 1
* link it all together using winegcc
result: a wine app that does all the usual wine stuff at startup, and
then jumps into the entry point of "ardour". when it loads VSTs it
does so via the libfst API.
this is an ordinary wine app, except that 99.9% of its code is
actually a big linux shared library.
jfst (the JACK VST client) is based on the same idea, although its not
quite as blatantly obvious what is going on, since you can't build it
any other way. I asked Alexandre Julliard, the maintainer of the
Wine project, about the
libfst approach, and thought this list might be interested in his response.
- Michael Ost
First message (nov 8) when asked for a read on the libfst design he said,
"They have a wineserver and everything, they just bypass the preloader and
initial setup. It's a variant of the Mono patch. It should work OK as long
as both the host Linux app and the Windows DLL are well-behaved and don't
depend on things like memory layout, switching stacks, signals, starting
Linux threads, etc."
The problem is that this is wrong. Alexandre is
remembering stuff from
long, long ago.
the FST approach now involves absolutely no wine hacks at all. 
7:52 p.m.
Hi, thanks for this thread, I've been wanting to learn more
about how we could use (the newer) fst in our MusE for example.
I was not sure how to make MusE a wine app, though, as I was told to do.
Besides getting it to compile as a wine app, are there any major
tasks, traps, and conversions to look out for in the rest of the app?
Thanks. Tim.
On November 10, 2010 01:15:52 pm Michael Ost wrote:
I asked Alexandre Julliard, the maintainer of the Wine project, about
the libfst approach, and thought this list might be interested in his
response.
- Michael Ost
First message (nov 8) when asked for a read on the libfst design he
said, "They have a wineserver and everything, they just bypass the
preloader and initial setup. It's a variant of the Mono patch. It should
work OK as long as both the host Linux app and the Windows DLL are
well-behaved and don't depend on things like memory layout, switching
stacks, signals, starting Linux threads, etc."
And here's the second message, an exchange where I (MO) asked him (AJ)
for details about the above points:
MO: "Memory layout" - is there any risk that a DLL might see a smaller
VM size without the preloader? We are using the /3GB switch. Would that
be at risk?
AJ: It's not just size, but areas that are expected to be free that
would be occupied, for instance the DLL load address, things like that.
MO: "Switching stacks" - I can't see an audio DLL switching stacks.
Sounds like something a debugger might do...?
AJ: I know the jack library on Linux plays some strange games with the
stack to try to reduce latency. I'd imagine an audio DLL might try to do
stuff like that.
MO: "Signals" - seems very unlikely for a hosted audio DLL
"Starting Linux threads" - shouldn't happen from straight windows code.
AJ: These two would be potential problems in the Linux host application,
not in the DLL.
MO: "Etc" - and what might this be? %)
AJ: I'm sure there are other things, it's really hard to predict what
unspecified code is going to do. Basically everything we do during
startup was added because something depended on it, so anything that is
bypassed is a potential problem. Whether it will be a problem in actual
use can really only be determined by testing.
MO: This is all in WINE/loader, right?
AJ: Yes, but there's a lot of init code in ntdll too, particularly
regarding memory layout (that code will still be executed with the
libfst patch, but it may not be able to set things up the way it wants
to when not run at process startup).
On 11/2/10 10:06 AM, Paul Davis wrote:
> On Tue, Nov 2, 2010 at 12:53 PM, Michael Ost<most(a)museresearch.com>
wrote:
> Hi list,
>
> I am seeing what appears to be a 4 - 7 usec context switch time on a 3
> GHz Core 2 Duo machine with the 2.6 kernel, and 10 - 15 usecs on a 1.66
> GHz Atom. Is that reasonable? Does anyone have any tips on how to speed
> that up, if possible?
<snip>
Since
this has to happen twice per buffer, at a 32 sample buffer size
and with 10 VSTs, overhead accounts for about 14% of the CPU. On the
slower Atom machine, it would account for 33% of the CPU.
you can't reduce context switch times. the code involved is in the
kernel.
it is precisely this problem that led to FST, and the more general use
of FST by ardour (for example) where rather than going back and forth
between wine and the linux app, the linux app becomes a wine process
itself, and everything is in-process.
7:58 p.m.
On Wed, Nov 10, 2010 at 1:48 PM, Tim E. Real <termtech(a)rogers.com> wrote:
Hi, thanks for this thread, I've been wanting to
learn more
about how we could use (the newer) fst in our MusE for example.
I was not sure how to make MusE a wine app, though, as I was told to do.
Besides getting it to compile as a wine app, are there any major
tasks, traps, and conversions to look out for in the rest of the app?
there are zero changes to the rest of ardour when building it in this
way. ardour's a pretty complicated app, so i think you can take that
as a very likely "no".
--p
10:15 p.m.
On November 10, 2010 01:58:55 pm you wrote:
On Wed, Nov 10, 2010 at 1:48 PM, Tim E. Real
<termtech(a)rogers.com> wrote:
That's encouraging.
MusE already fully supported the old fst, so we've got code which I hope
would put us ahead of the game.
Thanks. Tim.
Hi, thanks for this thread, I've been wanting
to learn more
about how we could use (the newer) fst in our MusE for example.
I was not sure how to make MusE a wine app, though, as I was told to do.
Besides getting it to compile as a wine app, are there any major
tasks, traps, and conversions to look out for in the rest of the app?
there are zero changes to the rest of ardour when building it in this
way. ardour's a pretty complicated app, so i think you can take that
as a very likely "no".
--p
10:20 p.m.
On Wed, Nov 10, 2010 at 4:11 PM, Tim E. Real <termtech(a)rogers.com> wrote:
MusE already fully supported the old fst, so we've
got code which I hope
would put us ahead of the game.
i don't believe that torben & i ever released the wine-as-a-library
version of FST, so there effectively is no "old fst" in the sense that
has been alluded to by michael.
--p
10:41 p.m.
On November 10, 2010 04:20:02 pm you wrote:
On Wed, Nov 10, 2010 at 4:11 PM, Tim E. Real
<termtech(a)rogers.com> wrote:
That would be the old fst 0.6 (I think), just before the major changes.
MusE used to work with fst as a library, up to that version.
Tim.
MusE already fully supported the old fst, so
we've got code which I hope
would put us ahead of the game.
i don't believe that torben & i ever released the wine-as-a-library
version of FST, so there effectively is no "old fst" in the sense that
has been alluded to by michael.
--p
10:45 p.m.
On Wed, Nov 10, 2010 at 4:38 PM, Tim E. Real <termtech(a)rogers.com> wrote:
On November 10, 2010 04:20:02 pm you wrote:
fst has always been a library, though it includes an app as a demo/utility.
its earliest versions, the thing that torben & i wanted to make work,
was using Wine as a library too. that proved to be impossible in any
forward-compatible way (Wine would keep changing and what we had done
would break). hence the change to the new scheme i outlined earlier.
--p
On Wed, Nov 10, 2010 at 4:11 PM, Tim E. Real
<termtech(a)rogers.com> wrote:
That would be the old fst 0.6 (I think), just before the major changes.
MusE used to work with fst as a library, up to that version. MusE already fully supported the old fst, so
we've got code which I hope
would put us ahead of the game.
i don't believe that torben & i ever released the wine-as-a-library
version of FST, so there effectively is no "old fst" in the sense that
has been alluded to by michael.
--p
4916
days inactive
4924
days old
linux-audio-dev@lists.linuxaudio.org
14 comments
4 participants
participants (4)
-
fons＠kokkinizita.net -
Michael Ost -
Paul Davis -
Tim E. Real