On Thu, Apr 17, 2014 at 04:11:29PM +0900, michael noble wrote:
> Another question I
Sure it does, for a number of reasons. First, the periods of the
Jack backend and the alsa device are not synchronised and this
requires buffering. Equal periods are *not* the optimum, on the
contrary. Second, in a worst case scenario a2j could run near
the end of a cycle and j2a near the start, this again requires
buffering. Third, resampling adds latency as well since any
output sample depends on 'future' input.
The standalone versions of zita-x2y do report the correct latency
on their ports (probably the built-ins do it as well). Of course
this is not the value reported by tools such as qjackctl, which
will just display the theoretical latency of the backend.
A configuration using the dummy backend and zita-x2y will
always have more latency than one using the same device
with the same parameters directly in the backend.
The use of schedtool to run either Jack or zita-ajbridge is
questionable. Both set scheduling parameters on a per-thread
basis, and elevating the priority of the main thread won't
make them run better. It could even have an adverse effect
if the main thread ends up at higher priority than those
that really need it.
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
Linux-audio-user mailing list