On Thu, August 24, 2017 4:12 pm, Malik Costet wrote: In general that should be the case. When clients are too slow in processing you will sometimes see jackd messages about removing "zombified" clients. The behavior you described seems like jackd for some reason was processing the buffers as if the client app was still filling the buffers with new data, when in fact it had not. I think the original message said that jackd kept playing old audio. If it was just jack playing out the buffers with old data I would expect at most maybe 30 ms of audio (e.g. 512 samples per period, 3 periods, 48k samples/second) which would not really be recognizable audio. Was that what was meant by playing back old audio, or did it mean a recognizable section of audio, like 250 ms or more? In that case I would suspect the application was mismanaging the buffers in some way. -- Chris Caudle

On 08/24/17 22:30, Ralf Mardorf wrote: What exactly is the evidence of this? How can I know this? Application quits, sound keeps playing. The expected behavior: sound stops playing. The suspected cause: jackd fails to clean up after the disconnected client. This particluar application, sclang, doesn't quit by itself without Ctrl-C, if this isn't encoded in the script. Yuri

Am Freitag, 25. August 2017 08:25 CEST, John Rigg <j(a)jrigg.co.uk> schrieb: And, just to note: there are valid use cases for running jack without low latency demands. As a matter of fact, unless you do realtime (i.e. on-stage) audio processing/manipulation there's no need for low latency. Actually, it' s a pretty good idea to increase buffer sizes (read: high latency) when doing recordings. Cheers, RalfD

On Fri, August 25, 2017 9:05 am, Ralf Mardorf wrote: If jackd had a bug that caused it to continue playing buffers even when the client stopped processing (not confirmed, I think that is not very likely), but if that occured, even a very short buffer replayed continuously would make a very annoying buzzing noise from repeatedly playing the same samples. Given the information from Ralf Mattes it seems more likely that the sclang program that was stopped stopped providing data, but the scserver process kept processing the buffers, so from the jackd perspective the client was still active. I may try to replicate this weekend, but may be a little difficult, I changed my machine to Fedora 26, but SuperCollider is from the CCRMA repositories, and Fernando is still on summer holiday, so there is no Planet CCRMA for Fedora 26 yet. Maybe F25 packages will still work, I will try. -- Chris Caudle

On Fri, 25 Aug 2017 09:56:56 -0500, Chris Caudle wrote: Oops, my apologies to Ralf Mattes, I didn't notice this reply, where he also mentions the "latency" in the context of playing out the buffer.

On 2017-08-25 18:07, Yuri wrote: Are you saying in goes on indefinitely? So not a matter of some leftover buffers being rendered and then that's it -- but something that keeps going on, like the "buzzing noise" Chris mentioned? FWIW, I believe I've seen cases of this occurring in my testing, upon buggy shutdowns of clients. M.

On Fri, 25 Aug 2017 09:07:38 -0700, Yuri wrote: Hi, playing out the buffer was just a careful thought, since it wasn't clear that it is an endless buzz. Repeating my own comments, I don't experience this issue with jack 2, but if everything is ok, then I stop first playing an audio signal and after that I do not use Ctrl+C to quit the application/s, Instead I'm using a regular option provided by the application/s to quit. If something should go wrong, then I kill everything, including jack 2. I don't know why you want to interrupt a client playing an audio signal using Ctrl+C, if everything is ok. If you do this, since something else already went wrong, then I don't understand, why you don't want to kill jackd. Even if jackd should need the improvement you requested, consider to do such things in a logical order, as you would do when using expensive hardware in an audio studio. You wouldn't pull on a cable, to unplug a jack, then stop playing your instrument and after that turn of the amp. You would first stop playing, then turn of the amp and after that hold the plug to disconnect it. If something should go wrong, you would use the emergency stop switch to stop everything, you don't want that the emergency stop switch let the mixing console turned on. Regards, Ralf

On Fri, August 25, 2017 12:24 pm, Yuri wrote: When the supercollider script is killed, does jackd still show a connection to that port? In other words if you run jack_lsp or look in the qjackctl patch bay, does that still show a connection? Does your distribution have the jack_zombie tool built and installed? -- Chris Caudle

On 08/25/17 10:10, Ralf Mardorf wrote: Possibly OT, but I have experienced similar behaviour with jack2. John

On Sat, August 26, 2017 16:20, Ralf Mardorf wrote: Hi, i'm sure i missed a lot of this discussion but i wondered if there can be a single jack client c file that can trigger the issue. Such a client will allow the specialists to accurately trace the problem with their tools. I'm sure this will get (more) attention, and if the issue is understood the chances it gets fixed are good. Best regards Tom

On Mon, August 28, 2017 20:40, Fons Adriaensen wrote: If a client would catch Ctrl+C it can fill the buffers zero and this would be a non-issue? Cheers Tom

Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> writes: It doesn't matter. There is no point in Jackd being dependent on other applications' behavior for sensible behavior of its own, most particularly not on particular procedures for their termination. Unless they have explicitly set up actions to be taken after their termination (connecting Jack ports may count among that set: it might be an idea to require applications to mark its connections explicitly if it wants them to stay around after finishing, like jack_connect obviously would), Jackd should just revert to a "virgin" state when they terminate. You know: mixers that start with a _huuuuuge_ switch-on bump blowing out the bass speakers and waking all the neighbors are badly designed. Yes, one can work even with badly designed equipment, but there is no real necessity of making Jack badly designed for educational purposes. A "killall" is an emergency switch. You'll still get that bass bump if your mixer sucks. The power supplies give out in order of their buffering capacities even when the emergency switch is wired to everything at once. -- David Kastrup

On 08/25/17 12:26, Ralf Mardorf wrote: Are you a musician? Yuri

On 08/25/17 12:42, Ralf Mardorf wrote: Here you are very wrong, because this *is* a major usability problem in Jack. If I regularly encounter the problem, this is a major problem. Yuri

On Fri, Aug 25, 2017 at 12:29:10PM -0700, Yuri wrote: Ralf is well known on these lists for derailing threads like this. (I only know he is participating here due to quotes in other posts. I set procmail to send Ralf's emails to /dev/null years ago). John

On 08/25/17 12:48, David Kastrup wrote: A rational opinion in the sea of laymanship and blathering. Yuri

On Fri, August 25, 2017 12:40 am, Yuri wrote: There is a timeout parameter you can pass to jackd to specify how long the server waits for a slow client application. The default is 500ms, does that correspond to how long the audio keeps playing? There is also a parameter which can be passed to the jackd server to prevent the server from disconnecting slow clients. I do not know how to check the compiled defaults to see if they have been changed. The default should result in a crashed application being disconnected after half a second, you could change, for example try -t 50 to change the timeout to 50 milliseconds to see if that improves the behavior. There is also a -v option to cause more verbose messages, could help determine what the jackd server detects the application state at the time of stopping. -- Chris Caudle

This discussion goes crazy... Do you hear this looping buffer as Fons described? So we are taking about the application output buffers right? Then I would advice to look at the code that gives the buffers to the client, that is following the jack_port_get_buffer function code path, and see where (probably…) a simple « memset(buffer, 0,…) call has to be added at the appropriate place. Stéphane

On Tue, August 29, 2017 05:11, Yuri wrote: If It plays forever now that's indeed strange. Can you describe the sound? Is it "normal", like a song that just continues normally or more like crackle, arbitrary buffer data? Where does that data come from if the client is dead? Where do the clients get their data to put to jack? Do you see any remains of a dead client in the system?

Am Dienstag, 29. August 2017 16:24 CEST, Malik Costet <jack-devel(a)malikc.neomailbox.net> schrieb: I think it's waisted time to play the guessing game without better information to start with: how was the jack server started? Jackd's client treatment can be heavily changed with command line parameters (-t/--timeout and -Z/--nozombies). A reasonable test case (a sine tone is probably the worst tone to detect if it's one buffer played over and over or something still feeding frames to jack) and a test program that doesn't involve a client-server setup (where both client and server register with jack) and a real KILL signal to kill the sound generating process (sclang does all sorts of things after receiving a signal. Just do a proper sclang termination (i.e. send Ctr-D/EOF to the repl) to see what sort of shutdown handlers clang has (BTW, on my clang installation Ctr-C just does a clear-line, so no idea what clang binary Yuri uses ...). No, afaik that callback gets invoked from a (realtime priority) thread in the client process (that thread is managed by libjack.so, _not_ the server). Jackd merely signals that it's time to update the buffers. No, that callback is in the client's address space. Jackd and each client share memory segments (shared memory), IIRC one segment per client port. No client (process killed) -> no callback. My first hypothesis would have been a kill that doesn't kill all threads and a callback that would continue to fill the frame buffer, but that would be seen in ps ... That's why it's so important to know how jack was invoked. Killing a process does not remove shared memory segments (after all, that's why they are called "shared"). It would be a reasonable guess that these segments continue to live and jackd doesn't detect that the client disapeared (again: this depends on jackd's startup/configuration). BUT: Yuri claims that jack_lsp does not list those client ports! So, from the symptoms given to us (no client process/thread, jackd claims that the client disapeared) it's hard to think of a situation where jackd would still be reading samples from the shared memory (on Linux the first thing I'd do would be to look at those segments and check how many processes are using them: $ fuser -u /dev/shm/sem.jack_sem.1000_default_GrandOrgue). That's a libjack API, not a jack client/server API. Cheers, Ralf Mattes