Closed ianhundere closed 11 months ago
I've tried to replicate this without success.
It works well for me with Ardour 7 and Bitwig 5 (just installed from the flatpak with the 30 days evaluation license) . Everything on Debian bookworm (stable) running the included version of PipeWire and Ardour. The kernel is the RT version shipped with Debian.
$ uname -a
Linux asuka 6.1.0-9-rt-amd64 #1 SMP PREEMPT_RT Debian 6.1.27-1 (2023-05-08) x86_64 GNU/Linux
What Bitwig and PipeWire versions are you running?
You were testing this over the master branch with your patch, right?
Since the Debian 12 release (last month) I have not worked much with audio until now. I've been doing some testing and I've noticed that included version of PipeWire (0.3.65) was having some xruns when making connections besides having some timing issues (accurate timing is needed by Overwitch resampler to work smoothly).
I've upgraded it to the Debian testing version (0.3.76) which works much better.
What version of PipeWire are you running?
$ pipewire --version
pipewire
Compiled with libpipewire 0.3.76
Linked with libpipewire 0.3.76
hey, was just about to respond.
❯ pipewire --version
pipewire
Compiled with libpipewire 0.3.74
Linked with libpipewire 0.3.74
❯ uname -a
Linux t14s 6.4.6-76060406-generic #202307241739~1690928105~22.04~d567a38 SMP PREEMPT_DYNAMIC Tue A x86_64 x86_64 x86_64 GNU/Linux
5.0.4
of bitwig
You were testing this over the master branch with your patch, right?
and yes, that's correct. i also opened an issue for the pop!_os folks to bump pipewire. once that's merged, i'll test again. at the moment though, it's not really an issue for me.
I had this issue too occasionally and I suspected that there was something going on at the PipeWire level when making connections. It looks like it could be caused by this issue, which has been solved in the last release (0.3.80).
At least, I has not crashed for me yet.
Let me know if upgrading PipeWire fixes the issue for you.
looks like it's still waiting to be merged for pop!_os: https://github.com/pop-os/pipewire/pulls
i'll test when that's been merged, and will also, finally :slightly_smiling_face:, look into making a PR for AHfx+ for https://github.com/dagargo/elektroid
Has the issue been solved with the last PipeWire versión?
it was just merged for pop!_os, so i'll give it a go soon to see if the same issue occurs.
looks like that no longer happens, though when changing driver models i got the following:
❯ overwitch
ERROR:jclient.c:65:(jclient_thread_xrun_cb): JACK xrun
ERROR:jclient.c:65:(jclient_thread_xrun_cb): JACK xrun
...
ERROR:jclient.c:65:(jclient_thread_xrun_cb): JACK xrun
corrupted double-linked list
zsh: IOT instruction (core dumped) overwitch
❯ overwitch
ERROR:jclient.c:65:(jclient_thread_xrun_cb): JACK xrun
ERROR:jclient.c:65:(jclient_thread_xrun_cb): JACK xrun
ERROR:jclient.c:65:(jclient_thread_xrun_cb): JACK xrun
...
ERROR:jclient.c:65:(jclient_thread_xrun_cb): JACK xrun
ERROR:jclient.c:65:(jclient_thread_xrun_cb): JACK xrun
ERROR:jclient.c:65:(jclient_thread_xrun_cb): JACK xrun
ERROR:jclient.c:65:(jclient_thread_xrun_cb): JACK xrun
ERROR:jclient.c:65:(jclient_thread_xrun_cb): JACK xrun
ERROR:jclient.c:65:(jclient_thread_xrun_cb): JACK xrun
ERROR:resampler.c:265:(ow_resampler_read_audio): o2p: Unexpected frames with ratio 256.025046 (output 0, expected 48)
ERROR:resampler.c:265:(ow_resampler_read_audio): o2p: Unexpected frames with ratio 256.025046 (output 0, expected 48)
...
ERROR:resampler.c:265:(ow_resampler_read_audio): o2p: Unexpected frames with ratio 388.594439 (output 0, expected 48)
ERROR:jclient.c:65:(jclient_thread_xrun_cb): JACK xrun
...
ERROR:resampler.c:265:(ow_resampler_read_audio): o2p: Unexpected frames with ratio 274756.168789 (output 0, expected 48)
ERROR:resampler.c:265:(ow_resampler_read_audio): o2p: Unexpected frames with ratio 274796.806406 (output 0, expected 48)
ERROR:resampler.c:265:(ow_resampler_read_audio): o2p: Unexpected frames with ratio 274837.414546 (output 0, expected 48)
^CERROR:resampler.c:265:(ow_resampler_read_audio): o2p: Unexpected frames with ratio 274877.993207 (output 0, expected 48)
ERROR:resampler.c:265:(ow_resampler_read_audio): o2p: Unexpected frames with ratio 274918.542389 (output 0, expected 48)
What do you mean with "driver models"?
Perhaps it's something new in PipeWire that needs to be addressed as ratios as higher as 4 or as lower as 0.25 are very likely an error.
The ratios are the measured sampling rate of an Overbridge device / sampling rate of the host audio interface
.
ah, sorry about that i meant where you choose the audio drive in bitwig:
Definitely, Overwitch should handle this kind of changes and restart the internal resamplers.
I'll try to find a way to detect those.
While definitely there are issues with the latency due to the timing changes when restarting the audio system, I see no crashes and the ratios are similar.
Are you using the Overwitch master branch? In my setup, the JACK audio model seems to work better. No idea about the differences with the PipeWire one as the later is a replacement for the former and should be the same server.
However...
I think I might have come up with a solution to to both this issue and #52. It's possible for a client to be notified when another client it registered or unregistered. When that happens, the resampler can be restarted. I've chosen to restart the resampler only when clients are unregistered. Keep in mind that a restart implies an audio pause.
You can already try this change from the master branch. Let me know if this improves anything for you.
doh, i wasn't using the latest. will give'r another spin and keep ya posted.
seems all good here w/ latest and 0.3.82
of pipewire.
cheers 🍻
This is great news.
Thanks for taking the time to test it.
I'll continue testing #52 and, if everything goes well only #48 is left for version 1.1.
This was discovered when implementing AH+FX whereby if I change inputs/outputs in my daw's (bitwig) settings I get the following output:
which kills
overwitch
.As per @dagargo's suggestion, I used
gdb
to track where the issue was coming from and below are those findings:edit: just to followup, i tried changing back and forth from main to fx outputs and overwitch wouldn't die immediately, but eventually (3-5th time?) it would die w/ the
segmentation fault (core dumped)
error; hope this helps.