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.

Space required before macro. No functional changes.

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

Add support for nios2

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>

allow to use source date for man page generation

This reverts commit b4e7e875a7.

this enables making reproducible builds of this package

Fix Netjack crashes due to broken alignment

See discussion at http://comments.gmane.org/gmane.comp.audio.jackit/29516

Use ARM neon intrinsics for AudioBufferMixdown

This makes sure header checks work when the third party package is
installed in a non-standard location, as long as a pkg-config file is
found.

It is already defined by conf.define().

Release audio devices when alsa_driver_new fails

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.

fix missing void parameter in prototypes

Fix CPU hogging of the midi_thread()

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.

Fix 3 minor issues.