Re: [LAD] LV2 realtime safe memory pool extension

Seems like the post I'm replying to below isn't getting through to the
list. I got only the CC - which, BTW, I would normally not need at
all, as I'm on the list. :-)

On Thursday 08 November 2007, Nedko Arnaudov wrote:
[...]
> > What I meant was, if all the host provides is a pool of uniformly
> > sized chunks that are allocated when the plugin is initialized,
> > there doesn't seem to be much point in implementing it on the host
> > side.
> > The naïve host side implementatio would add exactly nothing,
> > compared to plugins just allocating their own pools during
> > initialization.
>
> There is point when you have several dynparam plugins that all user
> dynparam helper library requesting same sized chunks.

Yes... Point taken. Also, there is likely some probability of various
other plugins using "common" chunk sizes, or sizes somehow related to
the audio buffer size.

Then again, something that uses real time scripting would probably not
fit into such patterns at all - or maybe it would? Depends on the
implementation of the language, and how it's being used...

> > A proper real time manager, with arbitrary chunk sizes, would be
> > more motivated, as it adds functionality that plugins can't
> > implement internally; namely a shared memory pool.
>
> I'm not against it but I dont see use of it for lv2 zyn plugins /
> lv2dynparam / zynjacku. Except for enum value strings that I plan to
> make fixed (runtime) max size.

And of course, if there's no suitably licensed implementation that
works out of the box, I can se why you wouldn't want to go there
right now...

[...]
> > It's really only entirely ROM based synths (or "small fixed sample
> > set", in the case of software), virtual analog synths and the like
> > that *can* implement real time safe "program change" at all.
>
> One of ultimate goals of zynjacku is to make this happen with zyn
> plugins. Patch loading involves lv2dynparam communication that is
> realtime safe. It make take some time during which
> synth "parameters"
> will be in intermediate state, but this will depend on cpu power and
> preallocation size. Things that user has control of.

Well, yes; if it's only a matter of doing some calculations and
initializations "fast enough", it makes sense to go all the way and
make it properly real time safe.

> >> and for lv2dynparam plugin library internal
> >> operation too.
> >
> > It needs to "regroup" internally as a response to certain
> > parameter changes?
>
> no idea what you mean by regroup,

Sorry; I was thinking modifications of processing graphs
(adding/removing units), reallocation of delay buffers and that sort
of stuff.

> for each parameter, group or
> message there are internal fixed size structures.

Ok. We're talking "pool of event structs", basically.

[...]
> Point is whether arbitrary and fixed chunk allocators be in one
> extension. I tend to think that they should be separate because
> algorythms behind them are quite different and host may choose to
> implement only one of them.

Well, yes; pools of fixed size chunks are trivial to implement, and
very fast and cache effective - whereas a "real" memory manager is
not. Even a host that *does* implement the latter might take
advantage of knowing when a plugin really just wants a pool of fixed
size chunks, even if the systems are somehow connected behind the
scenes.

> Also most lock free algorithms are patented so this can be point of
> host supporting only one feature set.

You shouldn't need any lock-free constructs, unless I'm missing
something... Is it a requirement that real time safe allocations can
be done in other threads than the real time audio thread?

I would think that it's sufficient if other threads can make non RT
safe allocations. Then you can just have the corresponding call use
malloc() and mark the blocks so that the host's RT safe free() will
know how to handle these blocks. (They'd probably have to be passed
to a background thread for destruction. I simple - AFAIK, non
patented - single-writer, single-reader lock-free FIFO could be used
for that.) RT reallocations of such "non RT" blocks would just not
work, or you'd have to grab a block from the RT allocator and copy
the data, even when the original block could theoretically be
extended.

[...]
> The point is how should you define that feature A depends on feature
> B. LV2 in its current state, to my knowledge, does not treat this as
> bug.

Right... It does have to be defined somewhere, no matter what.
Probably not a good idea to just leave it to documentation and (the
as of now, non-existent) validation tools.

//David Olofson - Programmer, Composer, Open Source Advocate

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
'-- http://www.reologica.se - Rheology instrumentation --'
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Thu Nov 8 20:15:03 2007