Description of problem: When trying to use jconvolver in a manner similar to the one described here: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Simple-audio-post-processing, jconvolver fails to start with the error message "Jack buffer size change, exiting.". The command I'm trying to run is: PIPEWIRE_LATENCY=1024/48000 pw-jack jconvolver -s pipewire-0 ~/.config/jconvolver.config I tried with and without the PIPEWIRE_LATENCY variable, it does not help. Version-Release number of selected component (if applicable): jconvolver-1.0.3-5.fc34.x86_64 pipewire-0.3.25-1.fc34.x86_64 pipewire-jack-audio-connection-kit-0.3.25-1.fc34.x86_64 How reproducible: It might work sometimes (randomly?), but it is very rare occurrence. Steps to Reproduce: 1. Create a pipewire node with pw-cli create-node adapter '{ factory.name=support.null-audio-sink node.name=vsurround media.class=Audio/Sink object.linger=1 audio.position=FL,FR,RL,RR,FC,LFE,SL,SR }' 2. Start jconvolver with PIPEWIRE_LATENCY=1024/48000 pw-jack jconvolver -s pipewire-0 ~/.config/jconvolver.config Actual results: jconvolver exits immediately with the message "Jack buffer size change, exiting." Expected results: jconvolver keeps on executing and process the audio channels as described by the configuration file. Additional info: jconvolver output is set to "Xonar U7 MKII" USB sound card, not the internal audio.
Can you try with jack-audio-connection-kit? If this works it's a pipewire bug IMHO.
I cannot reproduce this issue any more with pipewire. It was updated to 0.3.26-1, so maybe the update fixed it, although I cannot be certain what exactly did it. Sorry to have bothered you, should I close the bug?
Actually, it does happen again. Running some applications using the sink used as jconvolver input may make jconvolver exit immediately with the "buffer size change" message. If I try to restart jconvolver while the application is using the sink, it exits immediately. I don't know yet how reproducible it is. It may depends on what is using the sink: playing a test sound with totem seems to work, it is more games like, for example, OpenMW that causes issues.
I did not try using jack-audio-connection-kit, I am not confident I could change the sound server without creating more issues. I really struggle to get consistent results. Some applications don't cause any trouble (totem, vlc), others (mostly games: openmw, supertuxkart, wine games, ...) make jconvolver exit with the usual message. I can make them work any way by switching the application to another sink (using pavucontrol), try to restart jconvolver, then switch back to jconvolver input sink (it may require several tries). After using this workaround, jconvolver will most often exits again when closing the problematic application. Except in a few cases, when it kept on running but the sound of other applications *not* going through jconvolver would become choppy until I stop jconvolver myself. During my tests, I created two surround nodes: one with pipewire (pw-cli create-node adapter '{ factory.name=support.null-audio-sink node.name=vsurround media.class=Audio/Sink object.linger=1 audio.position="FL,FR,RL,RR,FC,LFE,SL,SR" }') and the other with pulseaudio (pactl load-module module-null-sink object.linger=1 media.class=Audio/Sink sink_name=vsurround channel_map=surround-71). Even switching an application to the node *not* in use by jconvolver can cause the buffer size change. I don't know if it is related: since I first reported this I tried a few other audio filters, one of them is PulseEffects. It mostly works as expected but, some times, when opening or closing an application, there are very short cuts in PulseEffects audio stream. It could be that the jconvolver error is just one symptom of a larger pipewire issue.
jconvolver doesn't support changing Jack buffer size. You should test with jack alone, without pulse bridge or pipewire. I suspect some pulse client is causing the change in buffer size.
Jconvolver works fine with jack. I have been using it for years and I have never seen what is being reported here happen with jackd. In fact, I don't remember ever seen a jack application, or jackd itself, change the buffer size of the whole system randomly. Pipewire should not do that. There is no need for jack applications to have their buffer size changed on a whim of some other application, specially if the other application is not a jackd native client (ie: the operation of pipewire clients should not affect the operation of jackd clients).
Is "Jack buffer size" the same thing as pipewire's quantum? I've just learned about pw-top and I've noticed that the quantum value changes depending on which application is using the output. A music player (clementine) sets it to 4096 (or 2048 if I go through pulseeffects). jconvolver sets it to 1024 (or the value of PIPEWIRE_LATENCY if I use it). pavucontrol also sets it to 1024. A game (e.g. openmw) may set it to 512. When the quantum goes below jconvolver value, then it exits. Using PIPEWIRE_LATENCY=512/48000 when starting jconvolver helps it survive. The short cuts/stutterings I have with pulseeffects happen whenever the quantum value goes up (when I close a application that was forcing a lower quantum).
I'm assigning this to pipewire, as jconvolver works with jack
You can now (temporarily) lock the buffer size to some value with metadata: pw-metadata -n settings 0 clock.force-quantum <buffersize> And then you can let it run free again with: pw-metadata -n settings 0 clock.force-quantum 0 More info here: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Config-JACK#locking-buffer-size
> Jconvolver works fine with jack. I have been using it for years and I have never seen what is being reported here happen with jackd. In fact, I don't remember ever seen a jack application, or jackd > itself, change the buffer size of the whole system randomly. Pipewire should not do that. There is no need for jack applications to have their buffer size changed on a whim of some other application, > specially if the other application is not a jackd native client (ie: the operation of pipewire clients should not affect the operation of jackd clients). Consider this case that has nothing to do with pipewire: - Start jackd - Start jconvolver - Start ardour6, open a project - Go to window->audio/midi setup - change buffer size to something else -> jconvolver stops
(In reply to Wim Taymans from comment #9) > You can now (temporarily) lock the buffer size to some value with metadata: > > pw-metadata -n settings 0 clock.force-quantum <buffersize> > > And then you can let it run free again with: > > pw-metadata -n settings 0 clock.force-quantum 0 Hi Wim, that's great! What does "temporarily" mean? Is there a timeout? Or is it until the next pipewire restart? Also: is there an API to access these configuration changes? (so that, for example, qjackctl can be enhanced to know about pipewire and apply the proper configuration when asked to)
(In reply to Wim Taymans from comment #10) ... > Consider this case that has nothing to do with pipewire: > > - Start jackd > - Start jconvolver > - Start ardour6, open a project > - Go to window->audio/midi setup > - change buffer size to something else > > -> jconvolver stops Thanks, yes, jconvolver should support changes in buffer size. But... Your example is very different conceptually from what I was writing about. In your example a user is willingly changing the buffer size from inside a "professional" DAW application, and hopefully knows what he/she is doing. I was pointing out that starting an unrelated application could change the buffer size without warning, potentially upsetting an existing graph of interconnected jackd clients (for example, exiting jconvolver). There is no warning and you can't know beforehand which application will request changes (AFAIK). Hopefully the pw-metadata incantations outlined in the thread will help!
> Hi Wim, that's great! What does "temporarily" mean? Is there a timeout? Or is it until the next pipewire restart? Until a restart or until you reset it back to the defaults. > Also: is there an API to access these configuration changes? (so that, for example, qjackctl can be enhanced to know about pipewire and apply the proper configuration when asked to) These config changes use the metadata API, qjackctl could use them if there was a desired to add a pipewire backend. > Your example is very different conceptually from what I was writing about. In your example a user is willingly changing the buffer size from inside a "professional" DAW application, and hopefully knows what he/she is doing. I was pointing out that starting an unrelated application could change the buffer size without warning, potentially upsetting an existing graph of interconnected jackd clients (for example, exiting jconvolver). There is no warning and you can't know beforehand which application will request changes (AFAIK). Hopefully the pw-metadata incantations outlined in the thread will help! This is true. I was providing a counterexample for this statement: "Jconvolver works fine with jack. I have been using it for years and I have never seen what is being reported here happen with jackd. In fact, I don't remember ever seen a jack application, or jackd itself, change the buffer size of the whole system randomly. Pipewire should not do that. There is no need for jack applications to have their buffer size changed on a whim of some other application, specially if the other application is not a jackd native client (ie: the operation of pipewire clients should not affect the operation of jackd clients)." I'm now investigating how I can lock down the quantum for all DSP apps unless one of them requests a different quantum. This should avoid other consumer apps of messing with the quantum.
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07. Fedora Linux 34 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. Thank you for reporting this bug and we are sorry it could not be fixed.