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@lists.iem.at/message/RDKQWLSVMMWYGNUIPFDMOLWQJX2IDZBG/__;!!Mih3wA!Bj-tWL9L0xiqgRdmRLe-htHV4ythrBXjRTGKhvvE9IgeLDcY00TSJkKHfRM439uhTm_tCy7NA1xEhg$
---
pd-dev@lists.iem.at - the Pd developers' mailinglist
https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/YZFH3YGNVR2BFODXAZGPTHSRU3CB3Q3U/__;!!Mih3wA!Bj-tWL9L0xiqgRdmRLe-htHV4ythrBXjRTGKhvvE9IgeLDcY00TSJkKHfRM439uhTm_tCy4crqP11A$
---
pd-dev@lists.iem.at - the Pd developers' mailinglist
https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/BKTFMJJCMP2BIVAKV2MLWHWSR4VYQRF7/
---
pd-dev@lists.iem.at - the Pd developers' mailinglist
https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/BTSB7CSV3Q6BUE3ZDKVFHTOVDW6VIUFH/
