[CM] some questions re S7, real-time use, and memory allocation
Iain Duncan
iainduncanlists at gmail.com
Sun Nov 22 15:27:19 PST 2020
Another thought, my use case is mostly to make sequencers and algo
composition aids, not to render real time audio, so while timing is
important, I'm not going to be running a lot of code in the RT thread. It
will likely run once per minimum time unit, ie maybe 24 parts per quarter,
or something. Is there any reason I could not just have that function
(clocked from max) turn off the GC, do it's work, and then turn the GC back
on to clean up at the end of every tick? is that crazy talk?
Christos, I think you are using S7 in the audio thread in your VST thing
right? How are you dealing with that issue, or has it not bitten you?
iain
On Sun, Nov 22, 2020 at 3:21 PM Iain Duncan <iainduncanlists at gmail.com>
wrote:
> Thanks Bill, that sounds promising on the malloc front then. I'll take a
> look at the code.
>
> What I'm imagining right now is two s4m objects, one in high priority
> thread and one in the low, so that the majority of stuff is done in the low
> and the high is only used for lightweight timing critical tasks. If this
> doesn't pan out, I can always do the high priority thread stuff in Max or C
> instead, but it would be nice to be able to use S7 if possible. I *think* I
> should be able to keep the stuff in the high priority thread minimal enough
> to keep a handle on the garbage collection side, but dealing first hand
> with a garbage collector is new to me. (As in, I've done some soft
> realtime in C, and I've done work in GC'd languages, but none of that was
> in situations where I cared when the GC ran). If you (or anyone else) has
> pointers on how to learn more about that sort of thing, or how to watch
> when the GC runs, I'm all ears.
>
> thanks
> iain
>
> On Sun, Nov 22, 2020 at 3:05 PM <bil at ccrma.stanford.edu> wrote:
>
>> s7 calls malloc very infrequently; it has its own
>> malloc (mallocate and friends), calling malloc
>> only to get large blocks that it handles after that.
>> More likely to be a problem is garbage collection.
>> I haven't tried to use s7 in real-time, but I
>> would expect it to be a struggle.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20201122/82ef0782/attachment.html>
More information about the Cmdist
mailing list