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

PrevNext  Index
DateWed, 16 Feb 2011 12:56:20 +0100
From torbenh <[hidden] at gmx dot de>
To[hidden] at lists dot jackaudio dot org
In-Reply-ToJack O'Quin Re: [Jack-Devel] buffer size callback, revisit
Follow-UpArne Jacobs Re: [Jack-Devel] buffer size callback, revisit
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

-- 
torben Hohn
PrevNext  Index

1297857408.2483_0.ltw:2,a <20110216115620.GM3055 at siel dot b>