Notes:
The name length test still fails.
jack_client_open() will only allow 63 printable chars (unlike expected 64 == JACK_CLIENT_NAME_SIZE).
This difference isn't explained by the terminating NULL character. jack_client_name_size() takes care of that (returns JACK_CLIENT_NAME_SIZE + 1).
char arrays are initialized like arr[JACK_CLIENT_NAME_SIZE + 1] in many files und truncated like arr[JACK_CLIENT_NAME_SIZE].
Probable reason for 63: ':' is part of the client name and implicitely added later.
Name used by caller does not include ':' thus jack_client_open() will allow only JACK_CLIENT_NAME_SIZE - 1 printable chars.
This line in common/JackConstants.h gives a hint that ':' might be counted in for JACK_CLIENT_NAME_SIZE
#define REAL_JACK_PORT_NAME_SIZE JACK_CLIENT_NAME_SIZE + JACK_PORT_NAME_SIZE // full name like "client_name:short_port_name"
Currently many char arguments are described like
@param client_name of at most jack_client_name_size() characters
This can be confusing in two ways:
-jack_client_name_size() does include the NULL so it's one less 'payload' character
-if the returned size is used exactly as described for function jack_client_name_size() including NULL,
it won't work with jack_client_open() or jack_port_register() etc. because of another reduction (eventually for the ":").
!! This needs to be verified and documentation needs to be reviewed. !!
This reverts commit dde9f29a8e.
The commit introduced the following compiler error:
[100/255] Compiling posix/JackNetUnixSocket.cpp
../posix/JackNetUnixSocket.cpp: In member function 'int Jack::JackNetUnixSocket::NewSocket()':
../posix/JackNetUnixSocket.cpp:126:32: error: 'tos' was not declared in this scope
socklen_t len = sizeof(tos);
With glibc 2.16, we get following build error when building jack2:
[193/247] cxx: tests/iodelay.cpp -> build/tests/iodelay.cpp.4.o
../tests/iodelay.cpp:171:43: error: 'UINT32_MAX' was not declared in this scope
../tests/iodelay.cpp:171:55: error: 'UINT32_MAX' was not declared in this scope
../tests/iodelay.cpp:172:44: error: 'UINT32_MAX' was not declared in this scope
../tests/iodelay.cpp:172:56: error: 'UINT32_MAX' was not declared in this scope
In glibc 2.17 or older version, Header <stdint.h> defines these macros
for C++ only if explicitly requested by defining __STDC_LIMIT_MACROS.
We can't use <cstdint> since it requires C++11 standard.
This build issue found by Buildroot autobuilder.
http://autobuild.buildroot.net/results/369/369ce208ffea43dad75ba0a13469159b341e3bf5/
Signed-off-by: Rahul Bedarkar <rahul.bedarkar@imgtec.com>
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.
JACK2 added this function first, but the int return has been always wrong.
When JACK1 added JackPortRenameCallback it used the proper return.
Now that JACK1 supports port renames, devs will start to use it.
(previously it didn't work properly because of the missing jack_client_t* arg)
Some code might be broken because of this, but it's a very simple change,
and existing code would have been broken when changing JACK1 to JACK2.
Finally, JACK2 code never uses the int return value of this callback.
So there's no real reason to NOT change this.