Slogging along again on the new shared memory sampler – it’s coming along though. I discovered that some weird issues I was having (where sometimes the sampler would copy frames into the ADC and sometimes… blow up with -nan values getting written into the sampler) was – no surprise! – because of some goofs I made in the circular buffer implementation. Some classic writing beyond the boundary situations because I was wrapping on frames instead of samples.

The sampler is sampling! It’s a lot of fun to play with, and feels pretty responsive. I’ll be curious if there’s any noticeable latency with the python instruments, I haven’t tested them again since fixing the overflow bug.

In the meantime though, I’m leaking file descriptors somewhere and after sending 1,024 renders for playback the program blows up again complaining of “too many open files”.

I’m not sure where it’s happening yet, I’m closing all the file descriptors that get opened with shm_open, but unlinking the memory regions is still leaving them dangling… so something is holding on to a reference somewhere I guess.

I tried out valgrind with the –track-fds=yes flag but it isn’t reporting anything… my suspicion is I’m keeping a reference open to the shared memory segment somewhere and those calls to unlink the segments are piling up without actually doing anything? I don’t really know! That’s the current mystery.

update: Well, haha – I did have one dangling unclosed file descriptor. I love it when the mysteries amount to: look again, dummy. The sampler has been chugging along for a few hours now, but seems to be leaking memory…! It’s a slow leak, but some more time with AddressSanitizer is up next I guess.