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<m...@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. > > 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@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev