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

On a sidenote:

The JACK API documentation states for the buffer size callback, that it
is called in a "separate non RT thread", i.e., not in the process
thread. Which sounds to me that the process callback and the buffer size
callback can run in parallel.

Is this really the case? It means you'd have to allocate new buffers and
then somehow send those to the process thread in a lock-free way...?
What if the process callback has already been called with the new buffer
size, while the other thread is still reallocating the buffers?

I'm asking because the wrapper lib I'm working on is one of the cases
where I really need to know the buffer size...

Cheers,

Arne

On 16.02.2011 12:56, torbenh wrote:
> On Tue, Feb 15, 2011 at 12:12:45PM -0600, Jack O'Quin wrote:
>> 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?
> 
> because you dont know, which version your binary is linked to ?
> with the new semantics, you just do all your buffer allocations in the
> bufsize callback.
> 
> no need to preallocate buffers.
> 
> ------------------------------------------
> 
> float *buffer = NULL;
> jack_client_t *client;
> 
> void bufsize_cb( void * arg )
> {
>   buffer = realloc (buffer, jack_port_type_get_bufsize( client, JACK_DEFAULT_AUDIO_TYPE ));
> }
> 
> void old_bufsize_cb( jack_nframes_t nframes, void * arg )
> {
>   buffer = realloc (buffer, nframes * sizeof(float) );
> }
> 
> int main()
> {
>   client = jack_client_open( "bla", ... );
> 
>   if (jack_set_bufsize_changed_cb) {
>      jack_set_bufsize_changed_cb( client, bufsize_cb, NULL);
>   } else {
>      // with the old semantics, we need:
>      buffer = malloc (jack_get_bufsize() * sizeof(float) );
>      // if we omit this, buffer will not be allocated, and process_cb would
>      // crash on using it.
>      jack_set_bufsize_callback (client, old_bufsize);
>   }
> 
>   jack_set_process_cb();
> 
> 
>   jack_activate();
> 
>   sleep(-1);
> }
> 
> ------------------------------------------------
>>
>>> 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.
> 
> we are approaching API 1.0 ... this api should be as clean as possible.
> allocating mem only to reallocate it a few moments afterwards does not
> seem clean to me.
> 
> the problem is that the only valid point to use jack_get_bufsize() is
> inside a bufsize callback. all other points pose a race condition.
> 
> declaring new semantics for jack_get_bufsize() seems wrong.
> they will go unnoticed for a very long time.
> if we deprecate jack_get_bufsize() and introduce a new function,
> programmers are more likely to look at the docs for the new function,
> and do the bufsize dance ;)
> 
> 
>>
>>> 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
>> 
>> Jack-Devel mailing list
>> [hidden]
>> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
> 

1297869213.24885_0.ltw:2,a <4D5BE977.3060402 at gmail dot com>