Subject: Re: [linux-audio-dev] Jack and block-based algorithms (was: Reborn)
From: Paul Davis (pbd_AT_op.net)
Date: Wed Aug 14 2002 - 19:16:14 EEST
>On Wednesday 14 August 2002 15.51, you wrote:
>> On Wed, Aug 14, 2002 at 03:13:12 +0200, Anders Torger wrote:
>> > I'm considering a redesign of I/O handling in BruteFIR to add Jack
>> > support (I/O is currently select()-based), but since it is
>> > processes in blocks, perhaps it is not feasible?
>>
>> It makes it trickier. If the jack period size is giong to be fixed
>> (we havn't decided yet) and it's a power of two (usually is), its
>> easier, but otherwise you just need to buffer round it.
>
>Wouldn't it be possible to make an API where you report the latency to
>Jack,
this already exists: jack_port_set_latency() (and its companion,
jack_port_get_latency()).
and then Jack automatically aligns all applications? There is
>probably a bunch of problems doing so, I have not given it any deeper
>thought.
this was discussed on jack-devel (which is where this discussion
should be). we decided that it was not JACK's job to do this.
>The thing I don't like with sending initial zero samples which is
>required now, is that if the output is a file or into the edit window
>of an sound editor, you get a bunch of empty samples in the beginning,
>which you probably want to cut away.
you cannot ask questions like "if the output is a ..." in JACK. you
have no idea where the output is going, or to how many
destinations. you are asked to do a certain amount of work, and that,
as a JACK client, is your job. if you have no "real" data to provide,
then silence is the only other option. its up to whoever or whatever
receives your data to pay attention to the port latency if it cares
about that kind of thing.
--p
This archive was generated by hypermail 2b28 : Wed Aug 14 2002 - 19:16:22 EEST