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

PrevNext  Index
DateTue, 15 Feb 2011 12:06:55 -0600
From Jack O'Quin <[hidden] at gmail dot com>
ToPaul Davis <[hidden] at linuxaudiosystems dot com>
CcJACK <[hidden] at lists dot jackaudio dot org>
In-Reply-ToPaul Davis Re: [Jack-Devel] buffer size callback, revisit
Follow-UpPaul Davis Re: [Jack-Devel] buffer size callback, revisit
On Tue, Feb 15, 2011 at 11:46 AM, Paul Davis <[hidden]> wrote:
> On Tue, Feb 15, 2011 at 12:36 PM, Jack O'Quin <[hidden]> 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?
>
> that's part (2) of the proposal.

Part (2) only mentioned making it work for the new callback from part (1).

My question was: why not do that for the old-style callback as well?

> the problem is that clients can't know whether a given implementation
> will do that or not. so they cannot rely on their callback correctly
> setting the value(s).

I tried, but I just don't understand what you mean by this.

The client needs to initialize the values, and it needs a callback
that can reallocate them whenever called. There must be some simple
contradiction I'm missing here.
-- 
 joq
PrevNext  Index

1297793231.28972_0.ltw:2,a <AANLkTinzhEOh3k-22Pa0dtKXqggyzV6Q9XzDvM4YsmKs at mail dot gmail dot com>