I don’t have enough information yet to log a bug, but I have some evidence of some incorrect server shutdown behavior.
In my MixerChannel quark, I’m trying to stop bad values from going out, like this:
in = In.ar(busin, 1) * level; bad = CheckBadValues.ar(in, post: 0) + (8 * (in.abs > clip)); SendReply.ar(bad, '/mixerChBadValue', bad, 0); badEG = EnvGen.ar(Env(#[1, 0, 1], #[0, 0.05], releaseNode: 1), bad); in = Select.ar(bad > 0, [in * badEG, DC.ar(0)]);
Sometimes, not every time, when I recompile the class library, I get a big string of these posted:
BAD VALUES FOUND IN: MixerChannel(hwOut, localhost, 2, 2) [ /mixerChBadValue, 5, 0, 8.0, 8.0 ]
Dozens of them (meaning the trigger must be flipping between 0 and 8 many many times). The last time, I got 36 messages coming in (not an even division of the block size 64 – so it isn’t just a side effect of a loop – also,
36 > (64/2) so we know that it is not only one control block being processed).
“Bad value” code 8.0 means that the signal is above a preset clip level (not inf, not nan).
Before hitting “recompile,” the server’s signals are completely stable. It’s only at the moment of quitting the server that it starts firing out these OSC messages.
hwOut mixer is receiving from a few reverb send channels.
[ reverb mixer: synthgroup(empty), effectgroup(reverb synth), fader synth ]
–> [ hwOut mixer: empty groups, fader synth ]
The most obvious guess would be that one or more reverb synths start producing out of range values. But in that case, I would expect the reverb mixer to report the condition – and the reverb mixer’s fader synth should suppress the values, so hwOut shouldn’t report anything. That’s not the case here.
So I have to suppose it might be one of these cases?
- hwOut’s ‘level’ control bus has an out of range value.
- hwOut’s audio bus gets garbage data (and the synth is still processing) just before the server really shuts down.
This is only a minor annoyance – the fader synth logic does prevent bursts of noise reaching the speakers. But, what I’m seeing should be impossible if we are shutting down all signal processing before releasing bus memory. Something in the server is processing the SendReply, and the
in.abs > clip is getting data from somewhere, at a time when (I believe) all UGens should already have been destroyed. If I’m right about that, then something is not working correctly in the server’s shutdown sequence. That means there’s an uncontrolled situation which, for someone else in another context, might be bad for the equipment.
So I’m curious about this.
Does anyone have other ideas?
PS Edit: I wonder if it’s that the server’s RT thread gets a callback from the driver, while many but not all UGens have been destroyed. If that’s true, certainly the RT thread should be completely shut down before destroying any units, right?