Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
From: Benno Senoner (sbenno_AT_gardena.net)
Date: ke syys 22 1999 - 19:40:25 EDT
On Wed, 22 Sep 1999, Juhana Sadeharju wrote:
> >From: Paul Barton-Davis <pbd_AT_Op.Net>
> >
> >Just to float an idea: instead of having the GUI run by anything
> >related to the engine, put the parameters in shared memory (*).
>
> In my list too. I actully made the playline position transfer via shared
> memory in my improved XWave2. There were some problems... it was like
> the shared memory would have some delay before showing in another process.
> I printed the content of the shared memory play position and it was
> -1 for a long time even the engine updated the position (I heard the audio).
> Then when the value was finally available (after 1 to 2 seconds) in GUI
> process, the value was jumped to the current position (I never saw the
> earlier positions). Perhaps Linux did something weird paging stuff, who
> knows?
Hmm that sounds very very strange to me ...
Shared memory is shared memory that means if your write to this area,
reading from another process MUST give you the same value.
> >manipulation and possibly display of the parameters and other data,
> >accessed via shared memory. Benno will love this idea, I'm sure :)
>
> Me too! If GUI peaks the signal level (say) from one memory address, then
> there is no buffers or event queues which could freeze the system or cause
> delay (of the length of buffer) if GUI freezes for a moment.
> Ok, the engine would not freeze at all (if message queues are used for
> events, the engine should use nonblocking mode).
Yes, it the GUI freezes a moment that isn't too tragic, but
if the DSP engine freezes that would mean unsuitable for pro-audio.
But thanks to Ingo, this is a non-issue now.
Benno.
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:12 EST