buffer_size/sample_rate changes atomicity

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

buffer_size/sample_rate changes atomicity

Dmitry Baikov
Hello!
First of all I'd like to tell that JACK is great. And it'll become
even greater with midi, osc and video support :) (midi at least).

After implementing my first jack client I already have a question.
If I understand correctly, client callbacks aren't called until
jack_activate(). But, they can be called immediately after
jack_activate() AND from the different thread.
Now, imagine, that I need to set up some things according to sample
rate or buffer size (or both). I will make it at startup calling
jack_get_() functions and then, using registered callbacks. But
there's a hole between initial setup and jack_activate(), where the
parameters may change and my callbacks won't be called yet.

The only application-level solution, coming to mind is to check params
at every process() call. In this case we actually do not need param
change callbacks...

Or the callbacks should be invoked on jack_activate()...

Dmitry.


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r 
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: buffer_size/sample_rate changes atomicity

Alfons Adriaensen
On Thu, Jun 09, 2005 at 11:02:23AM +0400, Dmitry Baikov wrote:

> After implementing my first jack client I already have a question.
> If I understand correctly, client callbacks aren't called until
> jack_activate(). But, they can be called immediately after
> jack_activate() AND from the different thread.
> Now, imagine, that I need to set up some things according to sample
> rate or buffer size (or both). I will make it at startup calling
> jack_get_() functions and then, using registered callbacks. But
> there's a hole between initial setup and jack_activate(), where the
> parameters may change and my callbacks won't be called yet.
>
> The only application-level solution, coming to mind is to check params
> at every process() call. In this case we actually do not need param
> change callbacks...
>
> Or the callbacks should be invoked on jack_activate()...

IIRC, you can only use the jack_get_() functions after jack_activate()
hase returned, and then you will also get callbacks, so AFAICS the
problem does not exist as you decribe it.

But there is of course another one in that case: your process callback
can be called before you have read the frame rate and/or buffer size,
and done any initialisation based on them. So you need to design it
so it does something sensible until then (e.g. zeroing all outputs
and return).

--
FA


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: buffer_size/sample_rate changes atomicity

Jack O'Quin-2
Alfons Adriaensen <[hidden email]> writes:

> On Thu, Jun 09, 2005 at 11:02:23AM +0400, Dmitry Baikov wrote:
>
>> After implementing my first jack client I already have a question.
>> If I understand correctly, client callbacks aren't called until
>> jack_activate(). But, they can be called immediately after
>> jack_activate() AND from the different thread.
>> Now, imagine, that I need to set up some things according to sample
>> rate or buffer size (or both). I will make it at startup calling
>> jack_get_() functions and then, using registered callbacks. But
>> there's a hole between initial setup and jack_activate(), where the
>> parameters may change and my callbacks won't be called yet.

Very good observation.  You are correct.  Very few people appear to
have noticed this.  There is a bug report...

  http://jackit.sourceforge.net/mantis/view.php?id=5

>> The only application-level solution, coming to mind is to check params
>> at every process() call. In this case we actually do not need param
>> change callbacks...

Unfortunately, the process() thread can't usually do anything about
it, because it is constrained to using only realtime-safe services,
which do not include memory allocation or mlock().

Although we've known about this design problem for a long time,
nothing has been done about it because it is hard to fix and has not
been a problem in practice.  JACK still does not allow changing the
sample rate (it probably never will), and buffer size changes are
presently turned off in the default configuration, because they do not
work on some platforms (mainly OSX, I believe).

>> Or the callbacks should be invoked on jack_activate()...

I think this is probably the best approach.

> IIRC, you can only use the jack_get_() functions after jack_activate()
> hase returned, and then you will also get callbacks, so AFAICS the
> problem does not exist as you decribe it.

Your recollection is incorrect.  They only make sense before
jack_activate(), and most JACK clients use them then.

> But there is of course another one in that case: your process callback
> can be called before you have read the frame rate and/or buffer size,
> and done any initialisation based on them. So you need to design it
> so it does something sensible until then (e.g. zeroing all outputs
> and return).

For now, the best approach is to use both jack_get_buffer_size() and
jack_set_buffer_size_callback() before jack_activate() and hope no one
changes the buffer size in the interval between.  

Eventually, we will probably close this window somewhat like Dimitry's
suggestion.  A patch for this would be helpful.  Be careful when
working on it, the concurrency issues during jack_activate() are quite
tricky.  If this were easy, I would have fixed it long ago.  ;-)

I think it's safe to assume that the sample rate will not change, at
least in the JACK 1.0 timeframe.  IMHO, we should make this an
"official" restriction.  The question keeps arising, and the current
situation places an unnecessary strain on application developers.
--
  joq


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: buffer_size/sample_rate changes atomicity

Stéphane Letz

Le 9 juin 05 à 17:54, Jack O'Quin a écrit :

> Alfons Adriaensen <[hidden email]> writes:
>
>
>> On Thu, Jun 09, 2005 at 11:02:23AM +0400, Dmitry Baikov wrote:
>>
>>
>>> After implementing my first jack client I already have a question.
>>> If I understand correctly, client callbacks aren't called until
>>> jack_activate(). But, they can be called immediately after
>>> jack_activate() AND from the different thread.
>>> Now, imagine, that I need to set up some things according to sample
>>> rate or buffer size (or both). I will make it at startup calling
>>> jack_get_() functions and then, using registered callbacks. But
>>> there's a hole between initial setup and jack_activate(), where the
>>> parameters may change and my callbacks won't be called yet.
>>>
>
> Very good observation.  You are correct.  Very few people appear to
> have noticed this.  There is a bug report...
>
>   http://jackit.sourceforge.net/mantis/view.php?id=5
>
>
>>> The only application-level solution, coming to mind is to check  
>>> params
>>> at every process() call. In this case we actually do not need param
>>> change callbacks...
>>>
>
> Unfortunately, the process() thread can't usually do anything about
> it, because it is constrained to using only realtime-safe services,
> which do not include memory allocation or mlock().
>
> Although we've known about this design problem for a long time,
> nothing has been done about it because it is hard to fix and has not
> been a problem in practice.  JACK still does not allow changing the
> sample rate (it probably never will), and buffer size changes are
> presently turned off in the default configuration, because they do not
> work on some platforms (mainly OSX, I believe).
>
>
>>> Or the callbacks should be invoked on jack_activate()...
>>>
>
> I think this is probably the best approach.
>
>
>> IIRC, you can only use the jack_get_() functions after  
>> jack_activate()
>> hase returned, and then you will also get callbacks, so AFAICS the
>> problem does not exist as you decribe it.
>>
>
> Your recollection is incorrect.  They only make sense before
> jack_activate(), and most JACK clients use them then.
>
>
>> But there is of course another one in that case: your process  
>> callback
>> can be called before you have read the frame rate and/or buffer size,
>> and done any initialisation based on them. So you need to design it
>> so it does something sensible until then (e.g. zeroing all outputs
>> and return).
>>
>
> For now, the best approach is to use both jack_get_buffer_size() and
> jack_set_buffer_size_callback() before jack_activate() and hope no one
> changes the buffer size in the interval between.
>
> Eventually, we will probably close this window somewhat like Dimitry's
> suggestion.  A patch for this would be helpful.  Be careful when
> working on it, the concurrency issues during jack_activate() are quite
> tricky.  If this were easy, I would have fixed it long ago.  ;-)
>
> I think it's safe to assume that the sample rate will not change, at
> least in the JACK 1.0 timeframe.  IMHO, we should make this an
> "official" restriction.  The question keeps arising, and the current
> situation places an unnecessary strain on application developers.
> --
>   joq
>
>

This notification issue is somewhat related to the "one thread on  
client side" model: client get notifications only after the clients  
thread has been started by jack_activate.

In  jackdmp where a "two threads on client side" model is used,  the  
"notification" thread is already started by jack_client_new. Thus  
clients can receive notications immediatly and this solve this kind  
of issue.

Stephane




-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r 
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: buffer_size/sample_rate changes atomicity

Jack O'Quin-2
Stéphane Letz <[hidden email]> writes:

> This notification issue is somewhat related to the "one thread on
> client side" model: client get notifications only after the clients
> thread has been started by jack_activate.
>
> In  jackdmp where a "two threads on client side" model is used,  the
> "notification" thread is already started by jack_client_new. Thus
> clients can receive notications immediatly and this solve this kind
> of issue.

Good point.  That may be the preferred approach in the JACK 2.0
timeframe.

I'd love to see JACK 1.0 completed relatively soon, so we can move on
to these more sophisticated solutions.
--
  joq


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r 
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: buffer_size/sample_rate changes atomicity

Alfons Adriaensen
In reply to this post by Jack O'Quin-2
On Thu, Jun 09, 2005 at 10:54:36AM -0500, Jack O'Quin wrote:
 
> > IIRC, you can only use the jack_get_() functions after jack_activate()
> > hase returned, and then you will also get callbacks, so AFAICS the
> > problem does not exist as you decribe it.
>
> Your recollection is incorrect.  They only make sense before
> jack_activate(), and most JACK clients use them then.

Yes, you're right, sorry for the confusion. I must have been misguided
by having been bitten once when trying to get the frame rate before
becoming a client or something similar.

Which means that the problem pointed out by the original poster is
real, as you confirmed. I kind of like his idea of having a callback
triggered by jack_activate().


--
FA




-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: buffer_size/sample_rate changes atomicity

Jack O'Quin-2
Alfons Adriaensen <[hidden email]> writes:

> Which means that the problem pointed out by the original poster is
> real, as you confirmed. I kind of like his idea of having a callback
> triggered by jack_activate().

I do too.  It creates no binary compatibility problems with existing
clients.  And, after the fix is available clients would no longer need
jack_get_buffer_size(), except as a convenience.
--
  joq


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: buffer_size/sample_rate changes atomicity

Paul Davis
>Alfons Adriaensen <[hidden email]> writes:
>
>> Which means that the problem pointed out by the original poster is
>> real, as you confirmed. I kind of like his idea of having a callback
>> triggered by jack_activate().
>
>I do too.  It creates no binary compatibility problems with existing

i do three.



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel