Well, it's best _if_ the memory can be allocated on stack to do so (better cache behavior). OTOH, if you're using jack you probably don't care about being as efficient as possible anyhow.
OTOH I didn't know that there was ever a version with pre-allocated memory - and yes, it's going to be complicated because of the need to react to changing buffer sizes - I'm not sure it's worth the trouble.
cheers
Miller
On 10/8/24 4:47 PM, Christof Ressi wrote:
but 95b614656cd62214d6779014e5173d8af697814b wasn't me :-)
Sorry :)
why don't we just allocate the buffer on the heap *once* before we start the stream?
So the original code did exactly this... @Miller I think we should go back to the original solution to avoid continuous (de)allocations on the audio callback.
I've noticed that the old code used a hardcoded max. buffer size of 4096 samples (BUF_JACK). Alternatively, we could get the actual buffer size with jack_get_buffer_size() and register a callback with jack_set_buffer_size_callback() to handle buffer size changes.
Christof
On 08.10.2024 23:28, IOhannes m zmölnig wrote:
On 08/10/2024 22:04, Christof Ressi wrote:
@IOhannes: why don't we just allocate the buffer on the heap *once* before we start the stream?
no idea. but 95b614656cd62214d6779014e5173d8af697814b wasn't me :-)
gfmdsaf IOhannes
--- pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...