pierreguillot
commented
6 years ago Indeed, there are many things that could be improved in the code. I think that even the concurrent queues must be changed/improved. For the moment, I tried to find a balance between readability and optimization. For example, I considered that the potential artifacts due to the use of std::string were negligible compared to the artifacts directly implied by Pd and libpd - because a lot of objects allocate and free memory in the audio thread for example. But to be honest, I didn't perform any test for the performance and even if Pd has restrictions for the concurrent access that not a reason to add more problem with the Camomile code... so, yes, perhaps it's time check that. Feel free to make suggestion and to create PRs. Perhaps I should create a specific branch for this?
I want to bring attention to an issue I found in the code - realtime safe code. By this I mean, using methods that do not lock the audio thread for too long, or for unspecified amounts of time (that is, unpredictable). This is the usual read about the subject http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-for-nothing
One of such examples in camomile's code is creating std::string objects in process function. Such objects use heap to store memory, this uses locks and as such is not realtime safe.
We can reduce the risk of audio drop outs (not to mention less CPU usage) if we replace the bad code with realtime-safe variants. On low-end devices like the MOD Duo, where CPU is quite limited, this makes a big difference.