[pulseaudio-discuss] No Use for JACK Transport

[Tanu Kaskinen]

On Wed, Jul 25, 2007 at 02:46:38AM +0200, Lennart Poettering wrote:
> On Fri, 13.07.07 03:22, Esben Stien (b0ef at esben-stien.name) wrote:
> 
> > There is no use for JACK transport in pulseaudio. As it is now,
> > pulseaudio won't output JACK audio when the transport is off. This is
> > wrong.
> 
> I am sorry? I don't understand?

Esben refers to the known misbehaviour in the JACK modules -
they don't do anything unless
jack_transport_query(u->client, NULL) == JackTransportRolling

That is totally unnecessary, except that the modules seem to
use the JACK transport API to calculate the latency
accurately. In my patched JACK sink (see #91) the latency is
a multiple of the processing block size and pretty much
constant. That's been working fine for me, but if a more
accurate calculation is required, the jack_frame_time and
jack_last_frame_time functions can probably be used.

OT: I used the term "processing block size" in the previous
paragraph. What's your preferred term? The JACK api calls it
buffer size, in my code I call it block size, it also could
be fragment size or chunk size etc. I recall you had a
discussion in IRC about similar terminology, and even though
it wasn't related to JACK, I think you have a clear opinion
about this and I'd like to consistently conform to it.

-- 
Tanu Kaskinen