On 09.10.2024 02:30, Miller Puckette wrote:
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.
It's not so much about efficiency and more about realtime safety. You really don't want to allocate and free large memory blocks continuously in the audio callback...
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.
It's not that complicated: allocate before starting the stream and reallocate in the buffer size callback.
An easier, but slightly wasteful, solution would be the original one: just overallocate by using a fixed large buffer size.
In both cases, you could still allocate on the stack up to a certain limit, but I don't really think this is necessary. After all, the audio callback does nothing but transferring samples between the jack buffers and the ringbuffers. In this case, performance does not matter that much, but realtime-safety does! (Keep in mind that the system allocator may need to take a lock.)
|Christof|
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...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/BKTFMJJCMP2...