jack_latency_range_t is
struct _jack_latency_range {
jack_nframes_t min;
jack_nframes_t max;
};
and jack_nframes_t is
typedef uint32_t jack_nframes_t;
so it's unsigned. Initialising it with -1 is invalid (at least in C++14). We cannot use {0, 0}, because latency_cb has
jack_latency_range_t range;
range.min = range.max = 0;
if ((range.min != capture_latency.min) || (range.max !=
capture_latency.max)) {
capture_latency = range;
}
so we must not have {0, 0}, otherwise the condition would never be true.
Using UINT32_MAX should be equivalent to the previous -1.
If configured with --clients=512 (translates to CLIENT_NUM), we exceed
the maximum stack size. CLIENT_NUM==500 still works, but let's allocate
the matrix on the heap to be safe.
Kudos to Markus Seeber for the initial bug triage.
Fixes#212
When compiling jack on nios2, compilation fails because NGREGS is not
defined. Since this is only for debug output on segmentation faults, stub
the debug print out like it's been done for other platforms before.
Inspired by
d11bb09529
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Call JackAlsaDriver::Close() when alsa_driver_new() fails, to
release devices acquired just before that call. Otherwise
JackAlsaDriver::Open() will never succeed again, as re-acquiring the
same device will fail with "A handler is already registered" DBus error.
The midi thread was always late after 2^31-1 Samples (~13.5h at 44.1kHz), because when there's no time limit, a uint64_t sample counter was compared against a signed 32bit INT_MAX to determine lateness. Now the CPU lockup will occur only after ~3 million years (at 192kHz), and because of the overflow it will presumably fix itself after a few milliseconds.