[pulseaudio-discuss] No Use for JACK Transport
Lennart Poettering
lennart at poettering.net
Mon Jul 30 13:54:43 PDT 2007
On Wed, 25.07.07 13:39, Tanu Kaskinen (tanuk at iki.fi) wrote:
> 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.
Hmm. The more exact the timing is we get the better we can do lip-sync
audio. If the hw supports it we want sample-exact latency
measurements. I am very sure that just "block" granularity is
insufficient.
> 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.
In PA I try to do without the term "block size" as much as
possible. PA doesn't enforce a fixed block size anywhere. We take what
we get and try to keep the memory blocks as large as possible, as
small as necessary.
Some people call it "fragment size", others call it "period size", even others
call it "block size", "frame size" or "buffer size" or whatever.
In PA I try to follow the following rules:
memblock: a non-mutable, ref-counted, variable-sized area in memory
memchunk: a fraction of a memblock, also variable-sized
sample: a single sample value for a single channel
frame: multiple samples, one for each channel in the context
Because OSS and ALSA require the notion of fragments/periods we follow
their notion in the respective driver modules. "fragment" is mostly
synonymous to "period" here. And the "buffer" is the concatenation of
a number of fragments/periods. So that buffer_size=frag_size*nfrags.
Confusing? Yes, of course!
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
More information about the pulseaudio-discuss
mailing list