[gmpi] Re: Reqs 5, 6, 11 for debate

  • From: Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Fri, 21 Nov 2003 07:54:55 -0500

>On Thu, 20 Nov 2003 RonKuper@xxxxxxxxxxxx wrote:
>
>> If Longhorn gives me page locked memory and CPU and disk reserves, you bet I
>> want to use it.  If I host a GMPI plugin that is allocating memory that
>> might fault during streaming, or reading from disk outside my reserve, I
>> can't host it within the scope of these new services.
>
>OK... well I don't think we have that in the requirements as yet. Can
>someone comment about whether Linux and OS X in particular have similar
>functionality modes for audio, and if/whether they're
>practical/needed/useful for acheiving decent low-latency performance
>under moderate to high system load on those OSes.

Both OS X and Linux offer similar functionality without placing any
requirements on applications at run time. 

On Linux, there are security issues, because the methods offered can
also be used to prevent the system from running any other
applications. But these are solved by the kernel and supporting
system-wide applications and configuration, not the application.

On OS X, which offers reservation scheduling already, there are still
security issues, but they also solved by the operating system, and
require no work on the part of the application.

And yes, they are required for low latency operation, and when used
they work incredibly well as the famous Johns Hopkins study shows (in
which Linux performed best under light non-audio load, and OS X just
inched it under load; both of them trounced Windows by a large
margin).

>If so, we need something like:-
>
>"Host applications may wish to run GMPI plug-ins in a special high
>priority context which has various restrictions on system calls and
>memory allocation. Therefore, GMPI must provide a means for:-
>- the host to tell if a plugin is capable of running in such a
>context
>and
>- plug-ins to be informed that they will be run in such a context.

Why? There is nothing that the DSP code for a plugin should be doing
that would ever violate the requirements anyway. Remember the rules:
the DSP code aka "process()" makes no system calls, does no I/O of any
kind, blocks on nothing.

The only sense in which this would be needed is if Longhorn requires
(for example) that all threads in a task/process that is using their
oh-so-shiny-and-decades-old functionality obey these rules. This would
be deeply problematic for hosts too. If that's the case, well, I don't
know what to say. How about: "you've got 2 years to migrate away from
Windows" ?

--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. 11-2003