Thanks so much Tim, I'll have to look into this. In fact, I hadn't even heard of coppwr, but now I definitely need to get it installed to play with. It looks like setting a global value sticks until you restart the computer or set to be automatic again (which blows my mind). I'm so used to being jack-brained that to me I need to close everything before changing settings, but it's not the case with pipewire it seems so far (at least with buffer sizes). Brandon Hale On 2/15/24 17:34, Tim wrote: > On 2/15/24 16:10, Brandon Hale wrote: >> Hello all, >> >> Do any pipewire users here know of a way to adjust the buffer for >> pipewire for jack applications? Ideally, I'm looking for something >> that is a gui app or client command that can be adjusted on the fly, >> or before loading an application. I want to try to reduce latency for >> a performance and pipewire has been working great otherwise. >> >> My system is the latest universalblue fedora sericea and I am using a >> pro-audio interface. >> >> Brandon Hale >> >> > > I use the comprehensive "coppwr". Perhaps overkill here but fun to > look at. > > https://github.com/dimtpap/coppwr > > > To cut to the chase, once it is up and running: > > Click Tools > Metadata Editor. > > Edit the boxes "clock.quantum" and "clock.rate", which are the desired > buffer size and sample rate. > > Be sure to click the corresponding "set" button when done editing a box. > > > That sets global values. > > I think you can set them on a per client basis too. > > > It appears to adjust on the fly. > > > Tim. > > MusE Sequencer project. > > > > _______________________________________________ > Linux-audio-user mailing list --linux-audio-user(a)lists.linuxaudio.org > To unsubscribe send an email tolinux-audio-user-leave(a)lists.linuxaudio.org

On Wed, Feb 21, 2024 at 02:03:41AM +0000, MS lists wrote: Does that mean that each Jack app can have its own buffer size and sample rate ? That completely destroys Jack's process model - that there is no buffering and hence delay between clients. Ciao, -- FA

On Wed, 21 Feb 2024, Fons Adriaensen wrote: My understanding is that the above tries to lock the device that app uses to these values. Then if other applications are started that connects only to the same device and/or application they get locked into that app/device's graph. Unless they ask for the same device with different values... This is part of the mix of pulse and jack. In pulse, an application starts and when it want to use an audio device, it sets it up the way it wants and then opens it for streaming after which it streams the audio in or out much like a pipe. In the case that the device is not in use, the device is directly set up for rate and latency. If the device is already in use, then a rate conversion stage is used. I am explaining this badly :( Pipewire has a default rate and latency. If an application starts and just connects to a jack port (that is using the jack api) it will get that rate and latency. However, there is a first come first serve kind of deal in there too. If an app asks for an alsa device through the pipewire or defaullt alsa device, that app will get _a device_ that it can set up. That device will, if pipewrie's default device is not currently in use, be pw's default device and the device will be set to the settings that app requests. A second app will get a psuedo device instead that will translate the stream to work with what the first app asked for. So how does an application that interfaces directly to the jack graph? It depends on the port it asks for (I think). That is it will get a jack graph that conforms to whatever that app (or device) is set to even if it is that first app that asked for the device through the ALSA or pulse API. I do not know what this means in the case where there are two desktop apps running that each have set up a different device with different rate/latency and a jack client connects to both chains somehow. I suspect audio will flow but that timing would be a train wreck. What does all this mean? If you want a stable jack graph, the first application you open matters. Use the various methods PW offers for setting the default values to what you want. Start something that uses the device ports you want to use or only ever use jack clients. And keep that port in use for your whole session. It you need to check an internet something that will play audio, so long as you have jack ports open to your device, that browser will get a an SRC block as a device whatever it asks for. I think this is about right but I may be wrong too. PW development has been moving too fast for me to keep up with. I do know that you are supposed to be able to use an instance of jack as a device for pw and that in that case, anything connected to those ports will be forced to that jack instances settings. I don't know how useful that is except for connecting a jack graph to applications that don't understand the jack API ("desktop" apps) or to use more than one device. Otherwise, just use the real jack ports. Len -- Len Ovens www.ovenwerks.net

PS, jack_bufsize is adjustable at runtime amazingly enough! On Thu, Feb 15, 2024, at 4:45 PM, Erik Schoster wrote: