Anyone using Jackd, with NetBSD 10.1?

533k3R

I can't seem to make client connections, with LMMS and Jackd. Both the server and client are reporting fd errors. Note that, my user is a member of wheel.

Qjackctl can't start jackd, because the new SUN driver lacks the "-n" argument and Qjackctl still issues it (not patched yet[maybe the new sun driver should accept it, but ignore values]). If the server is already running, when Qjackctl is launched, Qjackctl "should" detect it and report Jackd as active; that isn't happening.

It doesn't seem as though Jackd was built dependent on dbus, unless I'm missing it (dbus isn't a build time dependency).

I don't want to make a PR, unless someone can confirm there is an issue. If dbus has "somehow" been made a hard dependency, I would be tempted to make a PR on that; unless that is the only way Jackd "can" work, on NetBSD.

Any thoughts?

Extra: Patchage (and its dependency) seem to build well, on NetBSD. I wonder if it would make a nice/better/lighter alternative to Qjackctl. It built without any modifications. I haven't tested it, since I haven't yet connect to Jackd.

Edit: This is on a 32bit system; both pre-built binaries (pkgin) and custom builds (pkgsrc) have been tested.

JuvenalUrbino

533k3R I can't seem to make client connections, with LMMS and Jackd. Both the server and client are reporting fd errors. Note that, my user is a member of wheel.

It would be better to paste those errors here.

I've tested and used JACK on NetBSD and only had problems with Nvidia's integrated chips. Yes, jackd reports random error during playback, which I never bothered debugging. Please be ware JACK can't use realtime scheduling on NetBSD, and needs to be started with jackd -Sr -d sun.

Qjackctl can't start jackd, because the new SUN driver lacks the "-n" argument and Qjackctl still issues it (not patched yet[maybe the new sun driver should accept it, but ignore values]). If the server is already running, when Qjackctl is launched, Qjackctl "should" detect it and report Jackd as active; that isn't happening.

If the -n argument isn't removable through the setup UI, then it is a bug. I'm surprised nobody ever noticed this. Or maybe is the effect of some recent changes?

It doesn't seem as though Jackd was built dependent on dbus, unless I'm missing it (dbus isn't a build time dependency).

Qjackctl doesn't need dbus to start the jack server as far as I know.

JuvenalUrbino

Ok, indeed qjackctl tries to run /usr/pkg/bin/jackd -dsun -r22050 -p1024 -n2 -w16 when the selected backend is sun (so it keeps passing the default arguments for ALSA), and optionally prepends a-r option if real-time scheduling is disabled. I see no way of changing jackd arguments through the GUI besides the possibility of changing the values.

It seems worth to file a PR fo qjackctl.

In the meantime, I found a workaround. In the Setup Window , go to the Options pane, and check Execute script on Startup ; you may add /usr/pkg/bin/jackd -Sr -dsun here. Jack gets successfully autostarted in this way.

Pinging @nia

533k3R

@JuvenalUrbino, thank you, for your reply.

Are you using NetBSD 9 or 10 (64 or 32 bit)?

The errors I get are at client connection attempts. Jackd server is not successfully being connected to, so these are not Jacks errors (like xruns). These are socket errors.

LMMS, set for Jackd (Cannot read socket fd) and then falling back to dummy-audio-driver. Jackd, (Cannot read socket fd, Cannot notify add client, Cannot create new client).

Since your setup is working, could you also test that Qjackctl picks-up an already running Jackd server, on application launch.

Yes, I understand the real-time issue. I've not actually had an issue with that, on Linux, when running a lean and a task specific tuned system. It seems less of an issue, if you are not over taxing your system.

I also understand that NetBSD, even with Jackd working, may not perform as expected.

Note about Qjackctl, the old SUN driver did accept the "-n" argument (for period); it is even still in the Jackd manpages. Patched this in Qjackctl might cause an issue, with other platforms use the "a different?" SUN driver. That is why I mentioned the potential for accepting and ignoring the values, when Jackd is serving from NetBSD. There is probably a more elegant solution, but I haven't the scope to comment competently on it.

JuvenalUrbino

533k3R Since your setup is working, could you also test that Qjackctl picks-up an already running Jackd server, on application launch

Yes, it works as intended

533k3R

JuvenalUrbino Unless you can think of something I have missed, configuration wise, this may need to be a PR. Can you verify what NetBSD architecture and version you are using.

This could be like the issue with WINE (ld.elf_so), and only be affecting the x86 32bit architecture; which was also only a problem with NetBSD 10.

JuvenalUrbino

533k3R Can you verify what NetBSD architecture and version you are using.

Hi, sorry for the late reply. I'm on amd64, 10.1_STABLE.

The wine issue on i386 is being discussed on tech-pkg https://mail-index.netbsd.org/tech-pkg/2025/12/14/msg031755.html

533k3R

JuvenalUrbino There is actually two bugs, with WINE. The issue with ld.elf_so has a temporary patch. As for the other bug, I agree with @nia about v5 being made available again.

I've used WINE 3v with plenty of newer applications. It seems the main advantage, of more recent versions, is for gaming (any application needing GPU resources). If you were going to use a web-browser, over wine, you'd probably want a newer version.

But, the inevitable issue with having a functional version of WINE, and perhaps x86 32bit Jackd, is that I'd eventually start asking about issues building WineASIO; I can't remember now, some jack buffer long error (didn't dig into it). So, as long as Jackd and WINE are an issue, this whole WineASIO thing remains avoided. <- Poor attempt at humor here.

NetBSD is an excellent Operating System, and It takes resources to maintain it. These issues, I've pointed out, cast no shade on my interest in NetBSD. I understand that there isn't a ton of developer time available, and I'm in no hurry. Most of these issues are with packages, and specifically the x86 32bit builds. I think it reasonable that NetBSD itself get attention priority. On the packaging side of things, x86 32bit isn't as urgent.

In my schedule, I'm trying to work NetBSD back into my everyday life; start putting my head back into it (mostly pkgsrc/dreckly/wip). There has been a lot of change, since last time I could whip of a WIP port. Rust has really taken on a larger roll, and there are a lot more builds using tools like WAF, MESON, NINJA, etc.

533k3R

So, Jackd isn't built with Dbus, as a hard dependency, perse; but it seems "maybe" to be relying on it for socket communication.

Edit: So far, this is just guesswork. I can't imagine lack of dbus is the issue, here.
Edit:There is no "--dbus" in the default Pksrc configuration, for Jackd. WAF configuration actually selects "classic" as the default autostart driver.

533k3R

Okay, so I am now getting Jackd to segfault, when a client (qjackctl) attempts to connect.

First, since I am building from source, I had to modify the Qjackctl Makefile (Pkgsrc), and add "CONFIGURE_ARGS+= --disable-dbus" since I built QT5 without dbus support; otherwise the build will fail.

Running Jackd (jackd -v -Sr -d sun), in verbose mode, outputs this

Jack: JackSocketServerChannel::ClientCreate socket
Jack: JackSocketServerChannel::BuildPoolTable size = 3
Jack: JackSocketServerChannel::BuildPoolTable fSocketTable i = 1 fd = 9
Jack: JackSocketServerChannel::BuildPoolTable fSocketTable i = 2 fd = 10
Cannot read socket fd = 10 err = Undefined error: 0
Jack: JackSocketServerChannel::Execute : cannot decode header
Jack: JackSocketServerChannel::ClientKill ref = -1 fd = 10
Jack: Client was not opened : probably correspond to server_check
Jack: JackClientSocket::Close
Jack: JackSocketServerChannel::BuildPoolTable size = 2
Jack: JackSocketServerChannel::BuildPoolTable fSocketTable i = 1 fd = 9
Jack: JackSocketServerChannel::ClientCreate socket
Jack: JackSocketServerChannel::BuildPoolTable size = 3
Jack: JackSocketServerChannel::BuildPoolTable fSocketTable i = 1 fd = 9
Jack: JackSocketServerChannel::BuildPoolTable fSocketTable i = 2 fd = 10
Jack: JackRequest::ClientCheck
Jack: Check protocol client = 9 server = 9
Jack: JackRequest::ClientOpen

[1] Segmentation fault (core dumped) jackd -v -Sr -d sun

when Qjackctl loads, and attempts to connect to an already running Jackd server.

I paid a little more attention, while Jackd builds, and noticed plenty of:
JackSocket.cpp:40:35: warning: a⃗ directive output may be truncated writing up to 256 bytes in to a region of size 98 [-Wformat-truncations=]
40 | snprintf_res, size, "%s/jack%s%d_%d, dir, ext_client_name, JackTools::GetUID(), which);

Maybe this is something?

I can rebuild Jackd with "WAF_ARGS+= --debug", but am unsure of the correct breakpoint(s) to be setting.

533k3R

This is the backtrace, of the Jackd core dump.

Backtrace:

#0  0xabde9c08 in strlen () from /usr/lib/libc.so.12
#1  0xabdc1e11 in __vfprintf_unlocked_l () from /usr/lib/libc.so.12
#2  0xabdbd365 in vsnprintf_l () from /usr/lib/libc.so.12
#3  0xabdbd3fb in vsnprintf () from /usr/lib/libc.so.12
#4  0xac283010 in jack_format_and_log (level=level@entry=1, prefix=prefix@entry=0xac2ce7b8 "Jack: ",
    fmt=fmt@entry=0xac2d4b20 "JackEngine::ClientExternalOpen: uuid = %d, name = %s", ap=<optimized out>, ap@entry=0xa3d9f1d8 "\003") at ../common/JackError.cpp:74
#5  0xac283208 in jack_log (fmt=<optimized out>, fmt@entry=0x5852fb20 <error: Cannot access memory at address 0x5852fb20>) at ../common/JackError.cpp:113
#6  0xac2a274b in Jack::JackEngine::ClientExternalOpen (this=this@entry=0xabba8000, name=0xa3d9f3d4 "qjackctl", pid=16284, uuid=8589934595, ref=0xa3d9f2d4,
    shared_engine=0xa3d9f35c, shared_client=0xa3d9f360, shared_graph_manager=0xa3d9f364) at ../common/JackEngine.cpp:628
#7  0xac2bab6c in Jack::JackLockedEngine::ClientExternalOpen (shared_graph_manager=0xa3d9f364, shared_client=0xa3d9f360, shared_engine=0xa3d9f35c, ref=0xa3d9f2d4,
    uuid=0, pid=16284, name=0xa3d9f3d4 "qjackctl", this=0xabba8000) at ../common/JackLockedEngine.h:123
#8  Jack::JackSocketServerChannel::ClientAdd (this=0xaa3ff2dc, socket_aux=0xabc39d00, req=0xa3d9f3bc, res=0xa3d9f354) at ../posix/JackSocketServerChannel.cpp:131
#9  0xac2b6b0e in Jack::JackRequestDecoder::HandleRequest (this=this@entry=0xabc45540, socket=socket@entry=0xabc39d00, type_aux=23)
    at ../common/JackRequestDecoder.cpp:73
#10 0xac2b7616 in Jack::JackRequestDecoder::HandleRequest (this=0xabc45540, socket=0xabc39d00, type_aux=22) at ../common/JackRequestDecoder.cpp:63
#11 0xac2bb21c in Jack::JackSocketServerChannel::Execute (this=0xaa3ff2dc) at ../posix/JackSocketServerChannel.cpp:245
#12 0xac2976eb in Jack::JackPosixThread::ThreadHandler (arg=0xaa3ff3f0) at ../posix/JackPosixThread.cpp:63
#13 0xac1edee3 in pthread.create_tramp () from /usr/lib/libpthread.so.1
#14 0xabced760 in __mknod50 () from /usr/lib/libc.so.12
#15 0xabb6dc00 in ?? ()
#16 0xac1ef88f in pthread.makelwp () from /usr/lib/libpthread.so.1
#17 0xbb5c4f80 in _rtld_find_plt_symdef () from /usr/libexec/ld.elf_so
#18 0xbb5bc915 in _rtld_bind () from /usr/libexec/ld.elf_so
#19 0xbb5bc535 in _rtld_bind_start () from /usr/libexec/ld.elf_so
#20 0xac2f9c00 in ?? ()
#21 0xac2adf5b in jackctl_wait_signals (sigmask=sigmask@entry=0xac2f63ec <sigmask>) at ../common/JackControlAPI.cpp:689
#22 0x006cc5fe in main (argc=5, argv=0xbfbb7640) at ../common/Jackdmp.cpp:649

Full Backtrace:

#0  0xabde9c08 in strlen () from /usr/lib/libc.so.12
No symbol table info available.
#1  0xabdc1e11 in __vfprintf_unlocked_l () from /usr/lib/libc.so.12
No symbol table info available.
#2  0xabdbd365 in vsnprintf_l () from /usr/lib/libc.so.12
No symbol table info available.
#3  0xabdbd3fb in vsnprintf () from /usr/lib/libc.so.12
No symbol table info available.
#4  0xac283010 in jack_format_and_log (level=level@entry=1, prefix=prefix@entry=0xac2ce7b8 "Jack: ",
    fmt=fmt@entry=0xac2d4b20 "JackEngine::ClientExternalOpen: uuid = %d, name = %s", ap=<optimized out>, ap@entry=0xa3d9f1d8 "\003") at ../common/JackError.cpp:74
        buffer = "Jack: JackEngine::ClientExternalOpen: uuid = 3\000\000\030\361\331\243\360\360\331\243\001\000&\254\001", '\000' <repeats 11 times>, "h\361\331\243\200\345\\\273\000\340\\\273\000\224/\254\000\224/\254\277\300\036\254 \361\331\243l\361\331\243AJ&\254\000\224/\254\300\360\331\243\v\000\000\000\002\000\000\000\000\000\000\000\000\340\\\273\000\224/\254AJ&\254\370/&\254\200O\\\273AJ&\254l\361\331\243\000\224/\254h\361\331\243\001\000\000\000\000\000\000\000\001\000\000\000`W\000\000\000\000\000\000\000\224/\254\071\374N\004\205\036\\\273(\344\\\273"...
        len = <optimized out>
        log_function = <optimized out>
        __PRETTY_FUNCTION__ = "void jack_format_and_log(int, const char*, const char*, va_list)"
#5  0xac283208 in jack_log (fmt=<optimized out>, fmt@entry=0x5852fb20 <error: Cannot access memory at address 0x5852fb20>) at ../common/JackError.cpp:113
        ap = 0xa3d9f1d8 "\003"
#6  0xac2a274b in Jack::JackEngine::ClientExternalOpen (this=this@entry=0xabba8000, name=0xa3d9f3d4 "qjackctl", pid=16284, uuid=8589934595, ref=0xa3d9f2d4,
    shared_engine=0xa3d9f35c, shared_client=0xa3d9f360, shared_graph_manager=0xa3d9f364) at ../common/JackEngine.cpp:628
        real_name = "qjackctl", '\000' <repeats 56 times>
        refnum = <optimized out>
        client = <optimized out>
#7  0xac2bab6c in Jack::JackLockedEngine::ClientExternalOpen (shared_graph_manager=0xa3d9f364, shared_client=0xa3d9f360, shared_engine=0xa3d9f35c, ref=0xa3d9f2d4,
    uuid=0, pid=16284, name=0xa3d9f3d4 "qjackctl", this=0xabba8000) at ../common/JackLockedEngine.h:123
        lock = {fObj = <optimized out>}
#8  Jack::JackSocketServerChannel::ClientAdd (this=0xaa3ff2dc, socket_aux=0xabc39d00, req=0xa3d9f3bc, res=0xa3d9f354) at ../posix/JackSocketServerChannel.cpp:131
        refnum = -1
        __PRETTY_FUNCTION__ = "virtual void Jack::JackSocketServerChannel::ClientAdd(Jack::detail::JackChannelTransactionInterface*, Jack::JackClientOpenRequest*, Jack::JackClientOpenResult*)"
#9  0xac2b6b0e in Jack::JackRequestDecoder::HandleRequest (this=this@entry=0xabc45540, socket=socket@entry=0xabc39d00, type_aux=23)
    at ../common/JackRequestDecoder.cpp:73
        req = {<Jack::JackRequest> = {_vptr.JackRequest = 0xac2f30d4 <vtable for Jack::JackClientOpenRequest+8>, fType = 0, fSize = 77}, fPID = 16284, fUUID = 0,
          fName = "qjackctl", '\000' <repeats 56 times>}
        res = {<Jack::JackResult> = {_vptr.JackResult = 0xac2f30f4 <vtable for Jack::JackClientOpenResult+8>, fResult = -1}, fSharedEngine = -1, fSharedClient = -1,
          fSharedGraph = -1}
        type = Jack::JackRequest::kClientOpen
#10 0xac2b7616 in Jack::JackRequestDecoder::HandleRequest (this=0xabc45540, socket=0xabc39d00, type_aux=22) at ../common/JackRequestDecoder.cpp:63
        header = {_vptr.JackRequest = 0xac2f36c0 <vtable for Jack::JackRequest+8>, fType = Jack::JackRequest::kClientOpen, fSize = 0}
        req = {<Jack::JackRequest> = {_vptr.JackRequest = 0xac2f309c <vtable for Jack::JackClientCheckRequest+8>, fType = 0, fSize = 85},
          fName = "qjackctl", '\000' <repeats 56 times>, fProtocol = 9, fOptions = 1, fOpen = 1, fUUID = 0}
        res = {<Jack::JackResult> = {_vptr.JackResult = 0xac2f30bc <vtable for Jack::JackClientCheckResult+8>, fResult = 0},
          fName = "qjackctl", '\000' <repeats 56 times>, fStatus = 0}
        type = Jack::JackRequest::kClientCheck
#11 0xac2bb21c in Jack::JackSocketServerChannel::Execute (this=0xaa3ff2dc) at ../posix/JackSocketServerChannel.cpp:245
        socket = <optimized out>
        header = {_vptr.JackRequest = 0xac2f36c0 <vtable for Jack::JackRequest+8>, fType = Jack::JackRequest::kClientCheck, fSize = 0}
        fd = 10
        i = 2
#12 0xac2976eb in Jack::JackPosixThread::ThreadHandler (arg=0xaa3ff3f0) at ../posix/JackPosixThread.cpp:63
        obj = 0xaa3ff3f0
        runnable = 0xaa3ff2dc
        err = <optimized out>
        res = true
#13 0xac1edee3 in pthread.create_tramp () from /usr/lib/libpthread.so.1
No symbol table info available.
#14 0xabced760 in __mknod50 () from /usr/lib/libc.so.12
No symbol table info available.
#15 0xabb6dc00 in ?? ()
No symbol table info available.
#16 0xac1ef88f in pthread.makelwp () from /usr/lib/libpthread.so.1
No symbol table info available.
#17 0xbb5c4f80 in _rtld_find_plt_symdef () from /usr/libexec/ld.elf_so
No symbol table info available.
#18 0xbb5bc915 in _rtld_bind () from /usr/libexec/ld.elf_so
No symbol table info available.
#19 0xbb5bc535 in _rtld_bind_start () from /usr/libexec/ld.elf_so
No symbol table info available.
#20 0xac2f9c00 in ?? ()
No symbol table info available.
#21 0xac2adf5b in jackctl_wait_signals (sigmask=sigmask@entry=0xac2f63ec <sigmask>) at ../common/JackControlAPI.cpp:689
        sig = 0
        waiting = true
#22 0x006cc5fe in main (argc=5, argv=0xbfbb7640) at ../common/Jackdmp.cpp:649
        server_ctl = 0xabc4cc00
        server_parameters = 0xabc5a030
        server_name = <optimized out>
        master_driver_ctl = <optimized out>
        loopback_driver_ctl = 0x0
        replace_registry = 0
        options = 0x6cd498 "-d:X:I:P:uvshrRL:STFl:t:mn:p:C:a:"
        long_options = {{name = 0x6cccf5 "internal-session-file", has_arg = 1, flag = 0x0, val = 67}, {name = 0x6ccd0b "loopback-driver", has_arg = 1, flag = 0x0,
            val = 76}, {name = 0x6ccd1b "audio-driver", has_arg = 1, flag = 0x0, val = 100}, {name = 0x6ccd28 "midi-driver", has_arg = 1, flag = 0x0, val = 88}, {
            name = 0x6ccd34 "internal-client", has_arg = 1, flag = 0x0, val = 73}, {name = 0x6ccd44 "verbose", has_arg = 0, flag = 0x0, val = 118}, {
            name = 0x6ccd4c "help", has_arg = 0, flag = 0x0, val = 104}, {name = 0x6ccd51 "port-max", has_arg = 1, flag = 0x0, val = 112}, {name = 0x6ccd5a "no-mlock",
            has_arg = 0, flag = 0x0, val = 109}, {name = 0x6ccd63 "name", has_arg = 1, flag = 0x0, val = 110}, {name = 0x6ccd68 "unlock", has_arg = 0, flag = 0x0,
            val = 117}, {name = 0x6ccd72 "realtime", has_arg = 0, flag = 0x0, val = 82}, {name = 0x6ccd6f "no-realtime", has_arg = 0, flag = 0x0, val = 114}, {
            name = 0x6ccd7b "replace-registry", has_arg = 0, flag = 0xbfbb73dc, val = 0}, {name = 0x6ccd8c "loopback", has_arg = 0, flag = 0x0, val = 76}, {
            name = 0x6ccd95 "realtime-priority", has_arg = 1, flag = 0x0, val = 80}, {name = 0x6ccdd0 "timeout", has_arg = 1, flag = 0x0, val = 116}, {
            name = 0x6ccda7 "temporary", has_arg = 0, flag = 0x0, val = 84}, {name = 0x6ccdb1 "silent", has_arg = 0, flag = 0x0, val = 115}, {name = 0x6ccdb8 "sync",
            has_arg = 0, flag = 0x0, val = 83}, {name = 0x6ccdbd "autoconnect", has_arg = 1, flag = 0x0, val = 97}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}}
        i = <optimized out>
        opt = <optimized out>
        option_index = 0
        internal_session_file = <optimized out>
        master_driver_name = <optimized out>
        master_driver_args = <optimized out>
        master_driver_nargs = <optimized out>
        loopback = <optimized out>
        sigmask = 0xac2f63ec <sigmask>
        param = <optimized out>
        value = {ui = 2888799232, i = -1406168064, c = 0 '\000',
          str = "\000\224/\254\000\220/\254\000\224/\254\000\230/\254\000\234/\254\266H\\\273}v&\254\330t\273\277,\340\\\273\210t\273\277\001\000\000\000\000\000\000\000\214t\273\277\240t\273\277\000\340\\\273\000\324/\254\271B\\\273}\251l\000\352\277\310\253Xt\273\277\244t\273\277\000\340\\\273`2\310\253\001", '\000' <repeats 15 times>, "x\206\\\273\240\340\\\273`2\310\253\001\000\000\000\000\000\000", b = false}
        internals_list = {<std::__cxx11::_List_base<char*, std::allocator<char*> >> = {
            _M_impl = {<std::allocator<std::_List_node<char*> >> = {<__gnu_cxx::new_allocator<std::_List_node<char*> >> = {<No data fields>}, <No data fields>},
              _M_node = {<std::__detail::_List_node_base> = {_M_next = 0xbfbb73e4, _M_prev = 0xbfbb73e4}, _M_size = 0}}}, <No data fields>}
        slaves_list = {<std::__cxx11::_List_base<char*, std::allocator<char*> >> = {
            _M_impl = {<std::allocator<std::_List_node<char*> >> = {<__gnu_cxx::new_allocator<std::_List_node<char*> >> = {<No data fields>}, <No data fields>},
              _M_node = {<std::__detail::_List_node_base> = {_M_next = 0xbfbb73f0, _M_prev = 0xbfbb73f0}, _M_size = 0}}}, <No data fields>}
        it = {_M_node = 0xbfbb73e4}
        return_value = 0
       notify_sent = true

rvp

533k3R I noticed at least 3 issues in the jack sources.

The SEGV only happens if you turn on verbose logging with -v (and, this'll only manifest on 32-bit machines):
See here where %d is being used, but, jack_uuid_t is 64-bits. Simple reproducer below:

#include <stdio.h>

int
main(int argc, char* argv[])
{
	unsigned long long l = ~0ULL;		// 64 bits

	/* 
	 * On 32-bit machines, 8 bytes get pushed, but, only
	 * 4 bytes get popped, and the remaining 4 bytes
	 * gets taken up as the format string address:
	 *
	 * Segmentation fault (core dumped)
	 *
	 * On 64-bit arches, integer-promotion prolly papers
	 * over things, and it works fine there. But, GCC
	 * complains nonetheless:
---
qemu$ cc -Wall -o foo foo.c
foo.c: In function 'main':
foo.c:17:11: warning: format '%d' expects argument of type 'int', but argument 2 has type 'long long unsigned int' [-Wformat=]
   17 |  printf("%d %s\n", l, argv[0]);  // note mismatch
      |          ~^        ~
      |           |        |
      |           int      long long unsigned int
      |          %lld
qemu$
---
	 */
	printf("%d %s\n", l, argv[0]);		// note mismatch
	return 0;				// never reached
}

There're numerous places in the code where there're mismatches like this which don't manifest on 64-bit systems.
EDIT: this is issue #815 upstream.

This one is more buggy code:

Cannot read socket fd = 10 err = Undefined error: 0
Jack: JackSocketServerChannel::Execute : cannot decode header

This one is caused by the assumption that read(2) will always return the required no. of bytes. For disk files, you'll probably get what you asked for (barring errors, interrupts, etc.), but for socket reads, there's no such guarantee. read() may return after just 1 byte, or 2, or the entire length you asked for. Depends on the OS.

#1 & #2 are easily fixed, but, issue #3--which you probably haven't encountered yet--is

a NetBSD bug: PR# 56549.

File a PR (and link here--I'm not on those MLs). I can send patches for #1 & #2 easily.

(I had a preliminary patch for #3, but, that's on a HDD in a laptop which died, so I'll have to root around in my storage...)

533k3R

rvp Nice break down, and analysis. Waiting for the PR system, to come back up; as I'm not sending from the actual machine.