Luppp doesn't save nicely in NSM

[grammoboy2]

Luppp doesn't save nicely in NSM

Luppp GUI interface freezes when saving a NSM session with Luppp (kxstudio) included. It's takes minuts to get the app work again, if you get it working again at all. Something is going wrong there.

->GUI ringbuffer full
says the terminal in which I started Non-Session-Manager

Outside NSM it seems to save well

[grammoboy2]

Something with saving the samples in the NSM folder? This is a 'showstopper' for me at the moment.

[harryhaaren]

Hi, The issue here is that the UI thread does the disk writes. So any audiobuffers (loaded or recorded, doesn't matter) will need to be written to disk. The RealTime thread cannot do this safely (real-time gaurantees and disk-access are not a good combination..) so instead the UI thread does the work.

In practice, it is possible to spawn off a background thread to perform the actual work itself, and put the thread back to sleep when done. To get really fancy (crawl,walk,run...) a seperate thread could do each AudioBuffer instance, which whould mean shorter-save times too.

This is not a very complex chance, but would require somebody with good threading/real-time understandings, as we can't sacrifice the real-time gaurantees (obviously I hope :)

The GUI ringbuffer full messages indicate that the UI is no longer draining any messages from the RT thread, which is expected as it is stalled writing things to disk - so that is a good thing that it is flagging this issue... unfortunately printf() in an RT context isn't good. Some optimization there might be counting each time the ring buffer was full, and having the UI show up those "message xruns".

Are you using a very large amount, or very long audio-clips?

[grammoboy2]

I think it went wrong when having load 2 instead of just one beat. Probably these ones: https://freesound.org/people/FREDIOHEAD/packs/10529/