10 Nov
2010
10 Nov
'10
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.