[LAD] JACK latency API clarifications
zanga.mail at gmail.com
Fri Feb 21 15:41:12 UTC 2014
2014-02-21 17:21 GMT+02:00 Paul Davis <paul at linuxaudiosystems.com>:
> On Fri, Feb 21, 2014 at 10:04 AM, Stefano D'Angelo <zanga.mail at gmail.com>
>> Well, here
>> 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?
> 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
>> 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.
Ok, thanks a lot again.
More information about the Linux-audio-dev