[PD] Choices of IPC when using fast-forward

[Charles Z Henry]

On Thu, Mar 17, 2022 at 3:06 AM cyrille henry <ch at chnry.net> wrote:
>
> Hello Chuck,
>
>
> Le 16/03/2022 à 22:00, Charles Z Henry a écrit :
>
> [...]
>
> >
> > My conclusion there was that shmem can be used for asynchronous
> > inter-process communication with minimal risk to real-time.
> it can also be used between 2 synchronous process!
>
>   It's very
> > good as a fundamental object--it does not block, it does not
> > synchronize.
> that's the aim!
>
> > Notable limitations:
> > 1. Every process needs to know/use the same size for shmem ID's.
> is that a real limitation?
> Do you have a practicable example where one need to share memory of different size?

The basic thing I'm building is a network analyzer.  Send out a signal
X and record from the adc Y
Then, you can recover the impulse response.  I want to apply it to
passive electrical circuits (and loudspeakers) for measurement and to
room reverberation

To get a better estimate of the impulse response, you can increase the
measurement time.  The noise terms grow slower than the signal terms
do.
There's no way of knowing before the 1st measurement how long the
measurement needs to be.  So, it's always going to be adjusted at
least once


> > 2. Once allocated, a shmem cannot be re-sized.
>
> There is an allocate message now!
> It allow to change the Id and the memory size.

Ah, that's awesome!  I'll read it today.  I think I will have some questions

> But Antoine have problem compiling it on windows, so the last version is only available in deken for linux and osX.
> I'll be happy if anyone else want to gives a try at a windows compilation...
>
> > 3. Writing to/from an extremely large array all at once poses a risk
> > to real-time.
> yes, obviously, moving data from an memory position to an other need time.
> It's far from ideal, but in this situation of "extremely large array" you can spread over time your read/write.
>
> best
> Cyrille

Yes, that's a key feature I want to implement with abstractions.

There's no risk to doing the memory management and big transfers from
shmem to array in a "fast forward" or non-realtime process.
The toplevel, realtime, audio process should manage the staging of
data and have that ability to spread it out over time