Am Freitag, 25. August 2017 04:15 CEST, Yuri <yuri(a)rawbw.com> schrieb: > So far this is only your diagnosis and it's backed up by very little evidence. You haven't provided us with information about the real symptoms - "old audio" is a pretty broad description. Are we talking about the amount of audio data that gets processed in one jack process callback (as Chris Claude wrote, that would be sample-rate / (n-periods * buffer-size) ). I doubt you can even hear this. For anything longer, I think your diagnosis is off. Where should those sample came from? Who would be filling the shared memory buffers? I think for any serious debugging you need to provide us with better symptom descriptions. For example, as Ralf already did notice, sending an interrupt signal to a process doesn't mean that that process dies an instant death. The process could have installed a signal handler that performs, a graceful fade-out. Also, you wrote: I hope you now that sclang is not a jack (audio) client, it's only an interpreter that controls the supercollider server process (scsynth or supernova) by means of OSC messages. You either need to send the server a stop message or kill it. Can you describe what you would expect as a "clean up? AFAIK jackd plays the last filled buffer, then detects that the client fails to fill the buffers and "zombifies" (read: kills) the client - unless you told the server not to! Did you? Or did you crank up the client timeout? Cheers, Ralf Mattes