-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Allen & Heath Qu-Pac] regression since 0.3.53+ / no audio inputs unless manual selection of config profile ("Pro") in pulse audio control #16
Comments
i've since reverted / held back pipewire until |
I am not able to recreate this issue-- I'm able to record audio from a microphone into Bitwig using PipeWire 0.3.53. In the BitWig audio settings, do you have PipeWire selected for the #17 will update to 0.3.54 once testing is complete. |
i'll just reiterate that my setup is working with In the BitWig audio settings, do you have PipeWire selected for the Driver model option, or something else? Do you have an input bus added with the correct input selected? What computer and audio interface hardware are you using? again, i tested by reverting back to a working backup that had all signs point to this being an issue caused by the lemme know if you need any further information from me. |
@jacobgkau i noticed the PR was closed to update pipewire. when will that be available to download / test ? |
Today. Soon |
The update was released by this PR, please let us know if it fixes the issue. |
awesome, thanks for this. looks like it's working, but! i had to do the following for whatever reason:
this must get reset behind the scenes, or something of the sort. thanks again. |
reopening as i'm having to do the above steps each and every time my interface resets. |
I'm seeing something similar with Behringer X18 mixers since I upgraded Pipewire. One or more devices (I have 2 mixers and an SPL Madicon MADI interface) won't pass audio until "Pro Audio" is explicitly deselected and re-selected. While the system is in this state, the transport in Bitwig hangs when the play button is pressed and then the audio engine disconnects. I'm also seeing segfaults from Pipewire in my syslog:
|
@marksumm wanna post your issue here too to get more 👀 on it? https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2567 |
@jacobgkau looks like the latest release of pipewire may fix a few of the regressions "...as well as some channel mapping regressions." https://gitlab.freedesktop.org/pipewire/pipewire/-/releases/0.3.56 |
i wonder if it would cause issues if updates were pulled directly from the pw ppa. i'll try that and report back. as per @mmstick, i'll not do that 😉 |
This PR will bring 0.3.56: #19 If you'd like to confirm whether this new release fixes the issue with these DACs with many input channels, you can now install it with these commands:
I would reboot after that to make sure you're running the new version. When you're finished testing, you can remove the test repository from your system with these commands:
If the new release found in that PR fixes this issue, then I'll link the issue to the PR. |
@jacobgkau cheers, thanks so much for this. i'll test tonight / report back. |
@jacobgkau Thanks for that. Unfortunately, I still have both the profiles issue and the segfault issue. I've confirmed that the new version of pipewire is being used. Unfortunately, the issues discussed in this thread are only the tip of a very big iceberg, which appeared during the last batch of updates (both OS and Bitwig). I don't want to pollute the thread and it's well past the point of being able to conveniently separate issues into bug reports directed at individual projects or products. In general, things seem much happier when there are no X18 mixers attached, so I'm going to expand my AD/DA and connect everything to that instead. This will remove the need to initialise and maintain synchronisation across multiple devices. |
Be sure to report issues to the developer's repository. This is purely a packaging fork so the best I can do is backport new releases from the development repository. |
same issue here in that i have to unselect / reselect the "Pro" config profile in pulse audio control. |
@mmstick added |
ps when will wireplumber be updated ? |
Just to let you know, this staging release of Pipewire seems to have stabilised my setup when using JACK mode in Bitwig 4.3.2 (which also contained some JACK-related fixes), although I had to create a new audio configuration and recreate my inputs and outputs first. So, either there are issues with Pipewire affecting only native clients, or Pipewire mode in Bitwig is broken. Also created this issue in the Pipewire project: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2577 |
@ianhundere Have you tried Bitwig 4.3.2? Asking because I switched back to the .deb release this morning and now I'm no longer having profiles issues (still using the pipewire 0.3.56 staging release). See https://downloads.bitwig.com/4.3.2/Release-Notes-4.3.2.html |
It's funny, I am using that but I noticed that it's no longer labeled as a pre-release candidate. I'll try installing it again and see. Thanks for the heads up. edit: @marksumm just noticed your comment before your last about revertitback to JACK. is the profile issue fixed when using JACK ? |
@marksumm okay, i just tested this and this is the behavior:
|
@ianhundere Using 4.3.2 I have no profile issue with either JACK or Pipewire (at least so far today). I mentioned it because you said you were using 4.3.1 I still have other issues including the spinning on the first attempt to start. By the way, you can terminate the Bitwig audio engine process without quitting the whole application by right-click near the transport position. Update: I just encountered the profiles issue again. I'm now wondering if what really fixed it before was having |
@marksumm yah, i updated to hmm, weird...well i played around here a bit more and there were times the profile issues didn't happen. (using pipewire
i'm really not sure what to make of it. as for wireplumber, i mentioned that we were 2 versions behind here, pop-os/wireplumber#5, so hopefully that gets merged here soon for us to test. edit: @marksumm i turned off my interface / restarted the computer and i didn't have to select a config profile. weird...i wanna say it's fixed, but i don't know. @jacobgkau when |
Just removing the testing repo like I explained in my comment:
You'll start getting 404 errors when running |
ah okay, so we should remove with the steps above and then update like normal when it's officially released. |
@marksumm so after a bunch of restarts etc, i'm not experiencing either of the following:
i'm hesitant to close this issue until |
Linked the PipeWire PR to this issue since it sounds like the PR + a Bitwig update resolve the issue with these DACs. |
It does seem to be fixed. I think the one recurrence mentioned in my last update was in fact a total loss of synchronisation between audio devices. Probably re-selecting profiles caused them to be reinitialised. |
@marksumm looks like this issue is back for me:
then i unselect / reselect "Pro" via pulseaudio volume control:
|
latest alsa update fixed this |
@mmstick any way we could open this backup? the issue popped back up a bit ago, i opened these as well that i'm tracking. https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2567 |
@ianhundere Would you happen to be using 0.3.59? |
@mmstick edit: any tips on testing/upgrading to |
You can add it with |
@mmstick and final question, how do i go about reverting ? thanks for the awesome support / quick responses. |
|
no go 😢
|
@mmstick what's the suggested way of reverting to an older version of pipewire, would i rebase myself? |
You'd have to manually build the debian packages from the commit you want to revert to, and install them all the same time.
|
okay, i'll try to revert to thanks for your support. |
okay, so when i reverted obviously the
so i assume i need all those packages before i build. |
@mmstick i got as far as:
i guess i could spin up an ubuntu container to build. |
got a bit further in an ubuntu container but:
|
It is not enough for `buffer` to be alive in its current scope because when execution enters that branch, `format` will be set to `fmt`, which points inside `buffer`. And since `format` is used outside that scope, `buffer` must live longer. This was detected by ASAN when Audacity was starting up. ==25007==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7ffdbcfef560 at pc 0x7fe44ca95db3 bp 0x7ffdbcfeeda0 sp 0x7ffdbcfeed90 READ of size 4 at 0x7ffdbcfef560 thread T0 #0 0x7fe44ca95db2 in spa_pod_parser_pod ../spa/include/spa/pod/parser.h:67 #1 0x7fe44ca9a805 in spa_format_parse ../spa/include/spa/param/format-utils.h:44 #2 0x7fe44cad293a in port_set_format ../spa/plugins/audioconvert/audioconvert.c:1934 #3 0x7fe44cadad14 in impl_node_port_set_param ../spa/plugins/audioconvert/audioconvert.c:2038 #4 0x7fe44ca587e2 in configure_format ../spa/plugins/audioconvert/audioadapter.c:509 #5 0x7fe44ca60dff in negotiate_format ../spa/plugins/audioconvert/audioadapter.c:822 #6 0x7fe44ca62bbf in impl_node_send_command ../spa/plugins/audioconvert/audioadapter.c:846 #7 0x7fe45ea1c2f1 in node_update_state ../src/pipewire/impl-node.c:407 #8 0x7fe45ea5137e in pw_impl_node_set_state ../src/pipewire/impl-node.c:2251 #9 0x7fe45eb3355f in pw_work_queue_destroy ../src/pipewire/work-queue.c:142 #10 0x7fe45b2cd6f4 in source_event_func ../spa/plugins/support/loop.c:615 #11 0x7fe45b2c634f in loop_iterate ../spa/plugins/support/loop.c:452 #12 0x7fe45e9ebebc in spa_hook_list_clean ../spa/include/spa/utils/hook.h:395 #13 0x5561e03dc722 in main ../src/daemon/pipewire.c:131 #14 0x7fe45da3c28f (/usr/lib/libc.so.6+0x2328f) #15 0x7fe45da3c349 in __libc_start_main (/usr/lib/libc.so.6+0x23349) #16 0x5561e03db2a4 in _start ../sysdeps/x86_64/start.S:115 Address 0x7ffdbcfef560 is located in stack of thread T0 at offset 160 in frame #0 0x7fe44ca56fa9 in configure_format ../spa/plugins/audioconvert/audioadapter.c:475 This frame has 4 object(s): [32, 36) 'state' (line 493) [48, 56) 'fmt' (line 494) [80, 128) 'b' (line 492) [160, 4256) 'buffer' (line 491) <== Memory access at offset 160 is inside this variable
since updating to 0.3.53 audio is no longer inputted to my daw, bitwig 4.3.1.
i confirmed this was the issue by using timeshift to revert before the update, running bitwig to confirm audio was being inputted and then updated to 0.3.53.
maybe we can rebase to 0.3.54 to see if that fixes it?
https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/NEWS
The text was updated successfully, but these errors were encountered: