On Wed, 21 Feb 2024, Fons Adriaensen wrote:
On Wed, Feb 21, 2024 at 02:03:41AM +0000, MS lists wrote:
I just use:
PIPEWIRE_LATENCY=“128/48000” <your app>
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.
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
_______________________________________________
Linux-audio-user mailing list -- linux-audio-user@xxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to linux-audio-user-leave@xxxxxxxxxxxxxxxxxxxx
