[gmpi] Re: Req 76,78

  • From: Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Thu, 03 Feb 2005 22:20:03 -0500

>Interprocess communication will always be very hard to achieve under OSes 
>that 'protect' processes, and Windows is just about that (and even more with 
>upcoming 64bit ones).

with all due respect, if most of your experience of programming is
based on windows, you don't a very good sense of what is possible in
general. the whole of JACK is based on IPC, and it performs better (or
at least as well as) anything we've seen reported for various windows
APIs. i accept that window's capabilities for IPC may be lacking, but
they are not non-existent and they are not unusable.

>Right now it's also very inefficient, and probably related to the task 
>switcher. I don't know what's planned in longhorn here, but I don't see any 
>good reason for them to change that.

there are lots of good reasons for them to change it, primarily
because what they have right now is crap. they have the worst context
switch times of any OS that ever ran on an x86, and they know it.

>I also don't know shit about audio driver systems in longhorn, but what's 
>sure is that our sequencers won't start doing their processing at a driver 
>level anyway, so we're still 'stuck' with standard processes.

in longhorn, the plan is basically (AFAICT) to get audio to work
without kernel intervention once its running. not a bad idea,
actually. don't know it will work out in practice, and it requires
support for some new audio h/w specs.

>True, with such small latencies, there are some lower-level stuff in windows 
>that can sometimes interrupt the flow. But I don't see how this is related 
>with our problem anyway.

the only reason that the efficiency of IPC matters is that it can
block the realtime audio processing. its never slow enough to be
visible to the GUI user, even on windows, but if not done right, it
can certainly cause glitches in the audio stream *when the latency
settings are low*.

>> the people from GRAME got it work pretty well when they ported their
>> software to windows. its not as good as OSX or linux, but it provides
>> acceptable latencies when done correctly.
>>
>
>great, so why would people change from the VST specs, that can run in hosts 
>that offer a great latency, for GMPI that will run with just an 'acceptable 
>latency'?

i didn't say this, and its misleading to suggest that i did. GUI/DSP
separation doesn't affect latency unless the plugin developer doesn't
understand how to handle it correctly. just like the current
situation, where new VST programmers use mutexes to provide
inter-thread synchronization between the GUI and the DSP and can't
figure out why their audio clicks.

--p


----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules:  Please stay on topic.  You are responsible for your own
words.  Please respect your fellow subscribers.  Please do not
redistribute anyone else's words without their permission.

Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts:

  1. Home
  2. gmpi
  3. Archive
  4. 02-2005