`incudine:rt-start` fails with `FLOATING-POINT-INVALID-OPERATION` when run under Pipewire

[modula t.]

When running

(ql:quickload :incudine)
(incudine:rt-start)

with Incudine git master on Arch Linux, I get the following error:

arithmetic error FLOATING-POINT-INVALID-OPERATION signalled
   [Condition of type FLOATING-POINT-INVALID-OPERATION]

Restarts:
 0: [ABORT] abort thread (#<THREAD "audio-rt-thread" RUNNING {1001878103}>)

Backtrace:
 0: ((FLET SLYNK-BACKEND:CALL-WITH-DEBUGGING-ENVIRONMENT :IN "/home/modula/misc/sly/slynk/backend/sbcl.lisp") #<FUNCTION (LAMBDA NIL :IN SLYNK::DEBUG-IN-EMACS) {52C131BB}>)
 1: (SLYNK::DEBUG-IN-EMACS #<FLOATING-POINT-INVALID-OPERATION {1001898143}>)
 2: (SLYNK-SBCL::CALL-WITH-BREAK-HOOK #<FUNCTION SLYNK:SLYNK-DEBUGGER-HOOK> #<FUNCTION (LAMBDA NIL :IN SLYNK:INVOKE-SLY-DEBUGGER) {10018995BB}>)
 3: ((FLET SLYNK-BACKEND:CALL-WITH-DEBUGGER-HOOK :IN "/home/modula/misc/sly/slynk/backend/sbcl.lisp") #<FUNCTION SLYNK:SLYNK-DEBUGGER-HOOK> #<FUNCTION (LAMBDA NIL :IN SLYNK:INVOKE-SLY-DEBUGGER) {10018995B..
 4: ((LAMBDA NIL :IN SLYNK::CALL-WITH-LISTENER))
 5: (SLYNK::CALL-WITH-BINDINGS ((*PACKAGE* . #<PACKAGE "KROVO">) (*DEFAULT-PATHNAME-DEFAULTS* . #P"/home/modula/misc/lisp/krovo/") (* . :STARTED) (** . " ..)
 6: (SLYNK:INVOKE-SLY-DEBUGGER #<FLOATING-POINT-INVALID-OPERATION {1001898143}>)
 7: (SLYNK-SBCL::CALL-WITH-BREAK-HOOK #<FUNCTION SLYNK:SLYNK-DEBUGGER-HOOK> #<FUNCTION (LAMBDA NIL :IN SLYNK:SLYNK-DEBUGGER-HOOK) {100189957B}>)
 8: ((FLET SLYNK-BACKEND:CALL-WITH-DEBUGGER-HOOK :IN "/home/modula/misc/sly/slynk/backend/sbcl.lisp") #<FUNCTION SLYNK:SLYNK-DEBUGGER-HOOK> #<FUNCTION (LAMBDA NIL :IN SLYNK:SLYNK-DEBUGGER-HOOK) {100189957..
 9: (SLYNK:SLYNK-DEBUGGER-HOOK #<FLOATING-POINT-INVALID-OPERATION {1001898143}> #<unused argument>)
10: (SB-DEBUG::RUN-HOOK *DEBUGGER-HOOK* #<FLOATING-POINT-INVALID-OPERATION {1001898143}>)
11: (INVOKE-DEBUGGER #<FLOATING-POINT-INVALID-OPERATION {1001898143}>)
12: (ERROR FLOATING-POINT-INVALID-OPERATION :OPERATION NIL :OPERANDS NIL)
13: ((FLET SB-UNIX::BODY :IN SB-VM:SIGFPE-HANDLER))
14: (SB-VM:SIGFPE-HANDLER #<unused argument> #.(SB-SYS:INT-SAP #X7FC3A8AFE070) #.(SB-SYS:INT-SAP #X7FC3A8AFDF40))
15: ((FLET SB-THREAD::EXEC :IN SB-SYS:INVOKE-INTERRUPTION))
16: ((FLET "WITHOUT-INTERRUPTS-BODY-1" :IN SB-SYS:INVOKE-INTERRUPTION))
17: ((FLET SB-UNIX::RUN-HANDLER :IN SB-UNIX::%INSTALL-HANDLER) 8 #.(SB-SYS:INT-SAP #X7FC3A8AFE070) #.(SB-SYS:INT-SAP #X7FC3A8AFDF40))
18: ("foreign function: call_into_lisp")
19: ("foreign function: funcall3")
20: ("foreign function: interrupt_handle_now_handler")

I am not seeing any other error messages occurring other than the above. Even with logger-level set to :debug, this is all I get:

INCUDINE> (setf (incudine.util:logger-level) :debug)
:DEBUG
INCUDINE> (incudine:rt-start)

DEBUG: gc happened
DEBUG: realtime thread started
:STARTED
INCUDINE> (incudine:rt-stop)
DEBUG: realtime thread stopped
DEBUG: after realtime stop
:STOPPED
INCUDINE> 

incudine.config:*audio-driver* is set to :jack, but the same issue occurs with it set to :portaudio.

Otherwise, ~/.incudinerc is the same as the provided incudinerc-example file.

After the error occurs, I see the Incudine client in qjackctl's clients list, connected to my audio output as expected, however all other sound on the system stops. Pressing 0 on the error for ABORT brings me back to the REPL but running any dsp! produces no sound. Once (incudine:rt-stop) is called, audio on the system comes back.

My thinking is that this is caused by my use of Pipewire (0.3.24) as my sound server instead of JACK. Pipewire is a work-in-progress replacement for JACK and Pulseaudio on Linux. It covers both their use cases while (in theory) remaining compatible with them. Usually it's possible to run JACK programs under Pipewire without any problems by use of the pipewire-jack package, however this doesn't work for Incudine for me.

It's possible that this is an issue with Pipewire and not with Incudine but none of the other JACK programs I try with Pipewire (SuperCollider, Pure Data, Renoise, etc) seem to have any issues.

You can consider this a low priority issue since it's possible future versions of Pipewire will resolve the problem on their own.

Thanks for your work on Incudine, by the way. It's a very cool project and I'm planning to add even better support for it as a backend for my sequencing library in the future. I also appreciate that you already linked cl-patterns from the Incudine homepage :)

[Tito Latini]

I have tried PipeWire and removed JACK. The initialization seems ok but jack_cycle_wait() hangs after SIGFPE: ``` 14:41:54.495432 epoll_wait(9, [{EPOLLIN, {u32=2147503376, u64=139704548740368}}], 32, -1) = 1 <0.000008> 14:41:54.495460 read(15, "\353\0\0\0\0\0\0\0", 8) = 8 <0.000008> 14:41:54.495491 --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTINV, si_addr=0x7f0f9e024c67} --- ``` probably from cycle_run() in pipewire/pipewire-jack/src/pipewire-jack.c: ``` if (SPA_UNLIKELY(read(fd, &cmd, sizeof(cmd)) != sizeof(cmd))) { ``` There aren't SIGFPE if I remove jack_cycle_wait() and jack_cycle_signal(). Maybe that's an issue with PipeWire because generally JACK and PortAudio work without known problems, but anyway thanks for reporting, I'll continue to test PipeWire occasionally.

[Tito Latini]

Incudine uses a JACK process thread with jack_cycle_wait() and jack_cycle_signal(). After a pseudo tracing from pipewire source code: ``` jack_cycle_wait() --> cycle_wait() --> cycle_run() --> position_to_jack() ``` the SIGFPE (floating point exception) from `position_to_jack()` in `pipewire/pipewire-jack/src/pipewire-jack.c` is caused by ``` d->frame = (running - seg->start) * seg->rate + seg->position; ``` The variable `running` is declared `uint64_t`, but if `s->clock.position' is less than `s->offset`, the updated value is a big integer. For example, if the JACK transport is unused and ``` s->clock.position - s->offset = -1024 ``` the variable `running` is 18446744073709550592 and the first part of the test is true: ``` if (running >= seg->start && [...] ``` In practice, there are no problems if Jack transport is running. The following patch for pipewire is a possible solution (but I have not a gitlab account -- please help me with the communication): ``` diff --git a/pipewire-jack/src/pipewire-jack.c b/pipewire-jack/src/pipewire-jack.c index 0a621dde..38d7755c 100644 --- a/pipewire-jack/src/pipewire-jack.c +++ b/pipewire-jack/src/pipewire-jack.c @@ -1013,14 +1013,16 @@ static inline jack_transport_state_t position_to_jack(struct pw_node_activation d->usecs = s->clock.nsec / SPA_NSEC_PER_USEC; d->frame_rate = s->clock.rate.denom; - running = s->clock.position - s->offset; - - if (running >= seg->start && - (seg->duration == 0 || running < seg->start + seg->duration)) - d->frame = (running - seg->start) * seg->rate + seg->position; - else + if ((int64_t)s->clock.position < s->offset) { d->frame = seg->position; - + } else { + running = s->clock.position - s->offset; + if (running >= seg->start && + (seg->duration == 0 || running < seg->start + seg->duration)) + d->frame = (running - seg->start) * seg->rate + seg->position; + else + d->frame = seg->position; + } d->valid = 0; if (a->segment_owner[0] && SPA_FLAG_IS_SET(seg->bar.flags, SPA_IO_SEGMENT_BAR_FLAG_VALID)) { double abs_beat; ```

[modula t.]

Thanks for this. I'll submit a PR to Pipewire with this patch soon and will keep you posted with the respoonse.

[modula t.]

Created merge request 696 in the Pipewire gitlab.

[modula t.]

The patch was merged!

...Though unfortunately when I try Incudine in Pipewire with the patch, I still get a floating point exception when I do (rt-start)... I can press the ABORT restart and then I see incudine as a client in qjackctl, but running any dsp! in the REPL doesn't work; it just never returns unless I do C-c C-c to interrupt it. Does it work for you? Maybe it's something in my configuration that is causing the issue now...

[Tito Latini]

Thanks for your help and feedback. I cannot reproduce that problem after patching. I have tested with success (but without specific configurations): ``` # pipewire started from another terminal pw-jack sbcl ``` without priority settings on my system and ``` set_rlimits -L=/usr/local/lib64/pipewire-0.3/jack sbcl ``` with real-time scheduling priorities (`set_rlimits` is installed setuid root and `-L` sets LD_LIBRARY_PATH). Pardon my stupid question: do you link the updated library? Maybe `libjack*` files from pipewire installation are accidentally in multiple directories, i.e. `/usr/lib64` and `/usr/local/lib64/pipewire-0.3/jack`. I have: ``` shell> pw-jack sbcl lisp> (uiop:getenv "LD_LIBRARY_PATH") "/usr/local/${LIB}/pipewire-0.3/jack" ``` where `${LIB}` (not an environment variable) expands to `lib64` from dynamic linker. Is the date of the linked library after-patch? ``` ls -l /usr/local/lib64/pipewire-0.3/jack/libjack* ```

[modula t.]

Yes, my mistake, it looks like when I tested it was still using one of the older versions of the libraries on my system somehow (I am somewhat of a noob in this area). In any case I updated to Pipewire 0.3.29 today and Incudine is working flawlessly on it, so your patch did indeed do the trick. Thanks again :)