Re: [Jack-Devel] buffer size callback, revisit

On Tue, Feb 15, 2011 at 11:49 AM, torbenh <[hidden]> wrote:
> On Tue, Feb 15, 2011 at 11:36:07AM -0600, Jack O'Quin wrote:
>> On Tue, Feb 15, 2011 at 11:21 AM, Paul Davis <[hidden]> wrote:
>>
>> > this is true EVEN IF the client registered a buffer size callback. why
>> > so? despite the suggestion in the API docs for the buffer size
>> > callback, existing implementations do NOT guarantee to call the
>> > client's buffer size callback from within jack_activate(). this means
>> > that there is no reliable way for a client to know the port buffer
>> > size before its first process callback. the buffer size callback will
>> > notify it of later changes to the size, but not the initial size when
>> > it gets its first process() call.
>>
>> Perhaps a stupid question: why not ensure the buffer size callback
>> *is* invoked before the first process callback?
>>
>> Is that because it cannot be called in the realtime thread?
>
> how would you detect that its invoked ?

How would the callback know it's been called? I don't understand.

> jack-svn is invoking bufsize callback during jack_activate()
> there is no way, to be sure this happens.

That is the point I'm missing. Why not?

> so currently, one needs to allocate everything. then the bufsize cb will
> come, and results in reallocations. the old signature of the bufsize cb
> also does not allow determining the size of the midi port buffers.

I realize that it was overlooked when MIDI was added. I'm just trying
to understand why it's broken for audio buffers.

> the new functionname allows us do detect whether it will be called via
> weak linking. we are basically solving 2 problems at once.
>
> does it make sense to you now ?

Not quite. But, thanks for trying to explain it.

Regards,
-- 
 joq

1297793589.29699_0.ltw:2,a <AANLkTikQNHm1beeg+ZJcRm3=RNjiZJidV3pRphu3oR4g at mail dot gmail dot com>