On Wed, Jul 25, 2007 at 02:46:38AM +0200, Lennart Poettering wrote: > On Fri, 13.07.07 03:22, Esben Stien ([EMAIL PROTECTED]) 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 _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
