25 Sep
2020
25 Sep
'20
5:18 p.m.
On Fri, 25 Sep 2020 at 14:27, Lorenzo Sutton <lorenzofsutton(a)gmail.com> wrote:
On 24/09/20 14:57, Chris Caudle wrote:
Each app decides what kind of latency it wants, PipeWire dynamically adjusts the
graph buffer size (and latency) to the lowest requested latency.
The PipeWire replacement libraries can handle the same low latency as
jack clients.
They are in fact very similar to a jack client with some adapter and converters
added to make sure the pulse apps are not woken up too often.
So if ardour runs at 32 sample buffers and you have a browser linked
as an input,
PipeWire will pull 32 samples from the sample queue in the pulse layer from the
browser and push them into the ardour ports. The browser gets woken up after
32*N samples got pulled to match its requested latency so we don't wake it up
more often than it requested.
Wim
On Wed, September 23, 2020 6:24 pm, Chris Caudle
wrote:
Definitely an interesting development in the Linux Audio (Video) ecosystem.
I'm curious about something: how low latency (JACK) applications and
non-low-latency (Pulseaudio) applications like browsers will be able to
"co-exist".
Meaning, if I now use a pulseaudio sink to jack because, for example, I
want to pipe jack stuff to / from the browser or a 'consumer' messaging
app I need to keep frames / buffer (and therefore latency) relatively
higher, which is acceptable for this use case. On the other hand,
especially if recording (e.g. into Ardour but also if using MIDI which
uses softsynths in, say, Rosegarden), I try to push latency down. Pipewire is intended to replace jackd, not work
with jackd.
Recent article on the current state of pipewire:
https://blogs.gnome.org/uraeus/2020/09/04/pipewire-late-summer-update-2020/
How does / will this work with pilewire?
Lorenzo.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-user