Has anyone tried IDJC on PopOS with Pipewire (Pipewire is the replacement for JACK).
I can get IDJC to compile and install, but when running it hangs. There is s core dump in the syslogs:
Oct 12 20:32:43 xanxia kernel: python3[15390]: segfault at 0 ip 00007fb097dafbce sp 00007fb058bb3838 error 6 in libc.so.6[7fb097c28000+195000]
Oct 12 20:32:43 xanxia kernel: Code: 7f 00 c3 66 0f 1f 84 00 00 00 00 00 40 0f b6 c6 48 89 d1 48 89 fa f3 aa 48 89 d0 c3 48 3b 15 29 98 06 00 77 e7 48 8d 4c 17 80 <62> e1 fe 28 7f 00 62 e1 fe 28 7f 40 01 48 81 fa 80 00 00 00 76 >
If I run it from command line, sometimes I get python errors, sometimes, nothing.
Watching the qpwgraph map (the Pipewire replacement for qwjackctl) I see the IDJC ports show up for a second, then they disappear (I assume it's because of the core dump)
Now here is where it gets interesting:
If I open a Virtual Machine in Gnome Boxes (something as simple as a FreeDOS instance) then IDJC runs perfect!!!
Very strange. And even better, once IDJC is running I can close the VM and Boxes. At that point it's about 10/90 if I can run IDJC without the VM. Most of the time I can't but rarely I can.
So has anyone had any luck with IDJC and Pipewire on any Linux distro?
It's probably something that should be fixed as Pipewire is becoming standard. And once working it works great! I can use my Bluetooth headset, something that never worked with JACK. And no XRUNS.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Tried Pipewire in Gentoo and the IDJC backend crashed after or during the call to jack_client_open. Will wait for Ubuntu 22.10 before further testing.
Regarding the codebase, I have just added a code framework for backend testing that will allow in the future for writing stress tests. For now though, the plan is to get the backend up and stable on genuine JACK.
From your symptoms it looks like heap corruption.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I thought that the core dump was coming from the back end, just wasn't sure.
If you want to test Ubuntu, PopOS is based on Ubuntu but ships with Pipewire instead of JACK.
Did you try on Gentoo to run IDJC while a Gnome Boxes instance of something like FreeDOS was running to see if it work then like it does for me?
If there is any testing you'd like me to do, let me know. I'll be happy to help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I know you haven't announced anything yet, but I've been watching your commits. I checked out the latest commit and can happily report that IDJC is now working perfect with Pipewire on PopOS. 👍 😃 🙏
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Happy with how my testing went. Found that the jack buffer size callback does not run upon client activation whereas in JACK 1 or 2 it does. Called it manually just prior to client activation to prevent the crash. It's not pretty because there is a tiny time window during which the buffer size could change. It may be possible to safely use the thread init callback instead.
Suppose this should be reported to Pipewire.
Edit: testing revealed that everything is fine. The buffer size callback will be called before the process callback if the buffer size changes prior to client activation. Attempting to use the thread_init callback resulted in complete failure outside of the Pipewire environment so not going that route.
Last edit: Stephen Fairchild 2022-11-06
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Option 1 Gnome boxes allows dereferencing of NULL pointers.
Option 2 Gnome boxes causes the buffer size callback to run on client activation.
I don't know if there is an option 3 but I placed a print statement in the code so if it prints out "player read buffer allocated for ??? frames" If you comment out the explicit call on line 254 of main. c and it prints out the message you can conclude that the pipewire developers meant for the callback to run on client activation and some race condition is preventing it when Gnome boxes is not running and if it runs without the message that Gnome boxes is preventing segfault detection from working properly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Option 3 and I don't like it one bit: buffer pointer gets clobbered. This would require a sanity check. It should be NULL if realloc is not called on it unless calloc is broken and memory zeroing is not happening.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've been testing the latest code and have not noticed any problems with it. I've been using qpwgraph for the port connections so maybe that's why I haven't seen this.
Thank you for taking the time to make IDJC compatible with Pipewire. It works great. I can even use my Bluetooth headphones and USB microphone.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Has anyone tried IDJC on PopOS with Pipewire (Pipewire is the replacement for JACK).
I can get IDJC to compile and install, but when running it hangs. There is s core dump in the syslogs:
Oct 12 20:32:43 xanxia kernel: python3[15390]: segfault at 0 ip 00007fb097dafbce sp 00007fb058bb3838 error 6 in libc.so.6[7fb097c28000+195000]
Oct 12 20:32:43 xanxia kernel: Code: 7f 00 c3 66 0f 1f 84 00 00 00 00 00 40 0f b6 c6 48 89 d1 48 89 fa f3 aa 48 89 d0 c3 48 3b 15 29 98 06 00 77 e7 48 8d 4c 17 80 <62> e1 fe 28 7f 00 62 e1 fe 28 7f 40 01 48 81 fa 80 00 00 00 76 >
If I run it from command line, sometimes I get python errors, sometimes, nothing.
Watching the qpwgraph map (the Pipewire replacement for qwjackctl) I see the IDJC ports show up for a second, then they disappear (I assume it's because of the core dump)
Now here is where it gets interesting:
If I open a Virtual Machine in Gnome Boxes (something as simple as a FreeDOS instance) then IDJC runs perfect!!!
Very strange. And even better, once IDJC is running I can close the VM and Boxes. At that point it's about 10/90 if I can run IDJC without the VM. Most of the time I can't but rarely I can.
So has anyone had any luck with IDJC and Pipewire on any Linux distro?
It's probably something that should be fixed as Pipewire is becoming standard. And once working it works great! I can use my Bluetooth headset, something that never worked with JACK. And no XRUNS.
Tried Pipewire in Gentoo and the IDJC backend crashed after or during the call to jack_client_open. Will wait for Ubuntu 22.10 before further testing.
Regarding the codebase, I have just added a code framework for backend testing that will allow in the future for writing stress tests. For now though, the plan is to get the backend up and stable on genuine JACK.
From your symptoms it looks like heap corruption.
I thought that the core dump was coming from the back end, just wasn't sure.
If you want to test Ubuntu, PopOS is based on Ubuntu but ships with Pipewire instead of JACK.
Did you try on Gentoo to run IDJC while a Gnome Boxes instance of something like FreeDOS was running to see if it work then like it does for me?
If there is any testing you'd like me to do, let me know. I'll be happy to help.
I know you haven't announced anything yet, but I've been watching your commits. I checked out the latest commit and can happily report that IDJC is now working perfect with Pipewire on PopOS. 👍 😃 🙏
Happy with how my testing went. Found that the jack buffer size callback does not run upon client activation whereas in JACK 1 or 2 it does. Called it manually just prior to client activation to prevent the crash.
It's not pretty because there is a tiny time window during which the buffer size could change. It may be possible to safely use the thread init callback instead.Suppose this should be reported to Pipewire.Edit: testing revealed that everything is fine. The buffer size callback will be called before the process callback if the buffer size changes prior to client activation. Attempting to use the thread_init callback resulted in complete failure outside of the Pipewire environment so not going that route.
Last edit: Stephen Fairchild 2022-11-06
Still looking for with my testing also. So it really was just 1 line of code?
Just curious, do you have any idea why it worked when I had a Gnome Boxes VM running?
Something for you to test if it bothers you.
Option 1 Gnome boxes allows dereferencing of NULL pointers.
Option 2 Gnome boxes causes the buffer size callback to run on client activation.
I don't know if there is an option 3 but I placed a print statement in the code so if it prints out "player read buffer allocated for ??? frames" If you comment out the explicit call on line 254 of main. c and it prints out the message you can conclude that the pipewire developers meant for the callback to run on client activation and some race condition is preventing it when Gnome boxes is not running and if it runs without the message that Gnome boxes is preventing segfault detection from working properly.
Option 3 and I don't like it one bit: buffer pointer gets clobbered. This would require a sanity check. It should be NULL if realloc is not called on it unless calloc is broken and memory zeroing is not happening.
With line 256 commented out and boxes running I get this:
Without line 256 commented and no boxes I get this:
Interesting that the # of frames is different.
IDJC does not run perfectly on Pipewire. No guarantee that outgoing ports will be saved. Issue tracked down and reported. https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2841
They were quick to acknowledge the issue.
I've been testing the latest code and have not noticed any problems with it. I've been using qpwgraph for the port connections so maybe that's why I haven't seen this.
Thank you for taking the time to make IDJC compatible with Pipewire. It works great. I can even use my Bluetooth headphones and USB microphone.