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

  • From: "Vincent Burel" <vincent.burel@xxxxxxxxxx>
  • To: <gmpi@xxxxxxxxxxxxx>
  • Date: Thu, 20 Nov 2003 21:06:22 +0100

----- Original Message -----
From: "Angus F. Hewlett" <amulet@xxxxxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Thursday, November 20, 2003 7:49 PM
Subject: [gmpi] Re: Reqs 5, 6, 11 for debate


> On Thu, 20 Nov 2003 RonKuper@xxxxxxxxxxxx wrote:
>
> > >>>
> > so, you want us to pollute GMPI with extra junk just to to fit in the
> > misdesigns of Redmond?
> > <<<
> >
> > No, definitely not.  But I do want to make sure GMPI plugins will be
able to
> > work in these RT contexts.
>
> You can't make sure that ALL GMPI plugins are able to work in these
> contexts.. the best you can do is allow them to support it if they want
> to. I don't know anything about this new MS technology... why are they
> doing it? Will the latency performance of regular threads on Longhorn be
> worse than on 2K/XP?
>
> > Agreed.  But the memory touched by your realtime DSP code needs to have
been
> > allocated from this special pool.  And if your plugin does disk
streaming,
> > the disk IO calls need to come from a special place too.
>
> The diskstreaming plugins I've worked with do not do disk streaming from
> the process thread anyway... they have a seperate thread for that. I would
> expect that to be the usual design, but perhaps someone can contradict?

i don't know if it's the usual design (i hope :-), but it's the right
method. Especially when the latency become small (<20ms or 10ms) There is
too much waitcycle in I/O management and cache operation that it's not
really possible to implement that directely in the "DSP" real time thread.

let's add also that only one function is usually in RT Thread or High
Priority Thread, it's the ProcessSignal function, and normally this function
does not have to ask for memory, for screen access, or whatever other device
than the processor and the memory (memory already allocated of course).

VB



----------------------------------------------------------------------
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