-
-
Notifications
You must be signed in to change notification settings - Fork 35
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
JamesDSP prevents video playback until volume/audio button is clicked #74
Comments
I also noticed this issue happening randomly on my laptop. Initially, I linked it to power saving mode in KDE because the problem appeared to occur more frequently while it was on. The pipewire backend of this app is closely based on EasyEffects' implementation, so it is a good idea to keep an eye on the issues in their repo too.
I'm not sure where to start at the moment, I couldn't find anything relevant in pipewire's or jamesdsp's log yet. I'll probably search through the changelogs for wireplumber and pipewire, maybe there were some breaking changes I missed. |
I have tried to debug this in EasyEffects several times.. If this is the same bug we are seeing on our side just looking at PipeWire's logs is useless. We have to find a reliable way to make it happen so we look at PipeWire's logs at the moment the bug manifest itself. But even after many months I could not find a way. A long time ago I opened an issue about this in PipeWire's page. The main problem is that according to PipeWire's own tools like pw-dot everything is fine. The links are there and active. Things should work fine... But somehow they don't... |
I already pointed out the MR which caused the issue. Obviously this links rescan thing was useful for us. I will try to revert back |
Yes, it definitely helped. Edited --- /usr/share/wireplumber/scripts/policy-node.lua
+++ /etc/wireplumber/scripts/policy-node.lua
@@ -699,6 +699,8 @@
-- remove also not yet activated links: they might never become active,
-- and we should not loop waiting for them
Log.warning (link, "Link was not activated before removing")
+ scheduleRescan()
+ return
end
si_flags[si_id].peer_id = nil
link:remove ()
I kept the warning to see it actually still shows up, and it does:
But the sound works with no problems at all. So if someone needs a hotfix, here it is. |
Ahh I didn't see it as I only looked at open issues, sorry about that. ^^; Awesome that you've come up with a hotfix! I'll give it a try, and close the issue if it fixes it. |
Ahh yep, understood, since that was my same exact misunderstanding HAHA |
It should have been done months ago actually. Before WirePlumber made it to release. If only I knew earlier that the issue is actually widespread and not JDSP specific. |
If a link is not activated, don't remove it. Instead, schedule a rescan when a link activates, so that we'll handle it once it does. This is a workaround for some problems, see Audio4Linux/JDSP4Linux#74 However, the underlying cause is not understood.
Fix merged to WirePlumber upstream. |
This hasn't been an issue since the update, which is awesome :D |
Which update? There were no updates for JDSP or WirePlumber since. |
Since the merge request you linked before, which got merged into the master branch. I haven't encountered the issue mentioned in this thread since then |
Are you using
If you did not applied hotfix manually, this is magic. |
Probably |
bruh sorry all, did the dumb haha. I applied the hotfix manually, so of course it'd work 🤡 I'm not using edit: |
WirePlumber 0.4.13 released
|
Awesome ^^ is it time to close this issue? |
If it solves the issue for you, I think yes. |
I'm still having this issue in all apps now originally it was only in proton games. In fact as long as jamesdsp is running there is no audio raising the volume switching the output devices, etc does nothing. The only way to get working audio is to close jamesdsp |
Also having this issue... also using Garuda. How can I assist in solving the problem? |
WirePlumber 0.4.13? I have no issues on Arch after the update (as expected). AFAIK Garuda uses Arch repos for packages so should behave the same. Anyway, inspect your system logs. There can be unrelated problems. Generally collect
after the problem appears. |
thats what it shows for me |
@zany130 seems like you have some issues
or just pipe it to a file, e.g.
|
Those errors seems to be due to screen sharing as they pop up whenever I use discord screen share or launch obs so I don't think its related to this issue. Audio continues to work when those errors show up anyway, in fact nothing new is logged in the journal when I launch jamesdsp and immediately lose audio EDIT: on this boot I didn't even get the error it seems (the
here are the other two
|
Hmm, are you sure your audio setup is ok? Did you checked it with something like |
But now reading your original issue, I don't think this is the case. I see there are USB/Bluetooth audio devices in your system. The problem appears when you use them? Did you tried wired output? |
Well that was exactly the issue 🤦 unmuted it and now everything seems to be working |
Great! I'll see if I can implement a check that ensures that the sink is unmuted at all times. |
Hello, it appears that this has not been reported here despite it being quite a notorious issue (here's one such thread on the Garuda Linux forums).
This issue doesn't discriminate against browsers, and tends to randomly appear. It affects any form of video playback in the system, which means VLC and other media playback apps are affected as well. Many have solved the issue by not letting JamesDSP autostart, but the issue is that when it is started, it will sometimes exhibit this problem. It appears that once it happens during a session, it will always happen upon a restart of the program. It's not always guaranteed that the issue happens as soon as JamesDSP is autostarted- as is often in my case, it just randomly happens when it feels like it.
When this issue happens, Firefox and Chromium will suggest restarting the device. Clicking the volume icon, adjusting the volume or quitting JamesDSP will unfreeze the video, but skipping through the video will cause it to freeze again until one of the actions mentioned are taken (except for the quit one).
I love using JamesDSP for its bass boost, so I would prefer not to disable autostart or fiddle with volume buttons.
Here's my system information to help you troubleshoot, though this hasn't been limited to only one person or system: https://gist.github.com/jastx-jasmint/e0f9b61e6e70086bfed77f99cd3dddfe
The text was updated successfully, but these errors were encountered: