Re: [LAD] Faster context switch

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:
> On 11/2/10 10:06 AM, Paul Davis wrote:
> > On Tue, Nov 2, 2010 at 12:53 PM, Michael Ost<most@email-addr-hidden>
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.
>
> 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).

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Thu Nov 11 00:15:02 2010