21 Feb
2014
21 Feb
'14
4:41 p.m.
2014-02-21 17:21 GMT+02:00 Paul Davis <paul(a)linuxaudiosystems.com>om>:
On Fri, Feb 21, 2014 at 10:04 AM, Stefano D'Angelo <zanga.mail(a)gmail.com>
wrote:
Jack1 acccepts that other callbacks can block, and that doing so will
interrupt audio.
I wonder what the jack_set_sample_rate_callback() is for then, but at
Ok, thanks a lot again.
Stefano
Well, here
http://jackaudio.org/files/docs/html/group__ClientCallbacks.html
I only see that process has to be RT-safe and thread-init needs not,
but regarding others I have no clue. Is that stated somewhere else or
am I missing something?
if it doesn't say it has to be RT-safe, it doesn't have to be. That ought to
be obbvious also from the note on Jack2's design.
The threading design described above is specific
to Jack2. Jack1
delivers
all callbacks to the same thread (which necessarily means that
processing
audio is blocked by other callbacks). This is one of the major (and
largely
hidden) design differences between Jack1 and Jack2.
What truly interests me is whether non-process callbacks can block. It
seems that's not the case with Jack1 then?
this point I don't care.
it was part of the API very early on, then we decided we didn't want to
impose the possibility of change on clients. as time goes on, it becomes
clear (to me at least) that we should have implemented it.