26 Mar
2019
26 Mar
'19
1:30 p.m.
On Tue, March 26, 2019 19:38, Chris Caudle wrote:
Sure, don't get me wrong. Jack can do low-latency, synchronous processing
without loosing a sample and it should access the hardware as directly as
possible and run at the hw's clock.
The nice thing about jack is that its model is generic enough to a point
where it can also run as a high-latency client on-top of a potentially
lossy/inferior audio infrastructure, while keeping its intrinsic behavior
(synchronous, ...). The consequences of putting jack on-top of pulse can
be irrelevant for a given usecase.
As you pointed out, using jack-source, jack-sink modules for pulseaudio is
a setup known to be working. There is no immediate need for an
alternative.
We can think of scenarios outside of the existing, since its at no cost.
jack is flexible enough to adapt to almost any scenario, if needed.
Greetings
Thomas
On 2019-03-26
13:53, Thomas Brand wrote:
> making pulse a backend like alsa and others.
That is a very bad idea for various reasons. If you think it is super
useful then feel free to develop such a backend, or pay a contract
developer to do it for you, but the people who originally developed jackd
and the developers who currently maintain jackd as volunteers understand
the architecture of jackd and pulseaudio, and pulseaudio is a high
latency server which explicitly states that it will sometimes drop audio
samples. That is in no way what you want in an audio production
environment. The current jack-source and jack-sink modules are the
appropriate way to handle this situation, jackd is the low latency server
and controls the audio hardware, pulse becomes a client of jackd.