On Thu, Apr 11, 2024 at 2:09 PM Caoimhe &co <[email protected]> wrote: > > Note that the ringbuffer code in "s_audio_ringbuf.c" - for whatever reason > > - is missing all the memory > > barriers from the original PA implementation. This happens to work as the > > implementation is in another > > source file and (non-inline) function calls act as compiler barriers and > > Intel has a strong memory model, > > but if compiled with LTO this code may very well fail on other platforms, > > particularly on ARM. > > Yeah, I saw that. It's actually *worse* because the header file > multi-include protection uses the same preprocessor symbol as the JACK > ringbuffer implementation. I fixed that in my local git repo. How do I know > this? After a light code read, I switched to using the JACK ringbuffer > implementation, which I *do* trust.
Yeah, should probably be trusted, but only if you're using a Jack release which includes this commit from 2023-01-28: https://github.com/jackaudio/jack2/commit/75516ffe6d384223fbb32da704ad17a6af340961 _______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
