Re: [LAD] JACK latency API clarifications

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Stefano D'Angelo <zanga.mail@...>
Cc: The Linux Audio Developers' Mailing List <linux-audio-dev@...>
Date: Friday, February 21, 2014 - 3:21 pm

--f46d0444ea955ac64904f2ec2c0f
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Feb 21, 2014 at 10:04 AM, Stefano D'Angelo wrote:

>

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.

>

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.

--f46d0444ea955ac64904f2ec2c0f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 21, 2014 at 10:04 AM, Stefano D'Angelo <zanga.m=
ail@gmail.com
> wrote:

Well, here http://jackaudio.org/files/docs/html/g=
roup__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&#39=
;t say it has to be RT-safe, it doesn't have to be. That ought to be ob=
bvious also from the note on Jack2's design.

> The threading design described above is specific to Jack2. Jack1 deliv=
ers

ing
rgely

What truly interests me is whether non-process callbacks can block. I=
t
seems that's not the case with Jack1 then?Jack1 acccepts that other callbacks can block, and that =
doing so will interrupt audio.=A0I wonder what the jack_=
set_sample_rate_callback() is for then, but at

this point I don't care.it was par=
t of the API very early on, then we decided we didn't want to impose th=
e possibility of change on clients. as time goes on, it becomes clear (to m=
e at least) that we should have implemented it.

--f46d0444ea955ac64904f2ec2c0f--

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[LAD] JACK latency API clarifications, Stefano D'Angelo, (Thu Feb 20, 10:32 pm)
Re: [LAD] JACK latency API clarifications, Robin Gareus, (Thu Feb 20, 10:47 pm)
Re: [LAD] JACK latency API clarifications, Paul Davis, (Thu Feb 20, 10:45 pm)
Re: [LAD] JACK latency API clarifications, Stefano D'Angelo, (Thu Feb 20, 11:05 pm)
Re: [LAD] JACK latency API clarifications, Paul Davis, (Thu Feb 20, 11:08 pm)
Re: [LAD] JACK latency API clarifications, Stefano D'Angelo, (Thu Feb 20, 11:09 pm)
Re: [LAD] JACK latency API clarifications, Stefano D'Angelo, (Fri Feb 21, 2:38 pm)
Re: [LAD] JACK latency API clarifications, Paul Davis, (Fri Feb 21, 2:51 pm)
Re: [LAD] JACK latency API clarifications, Stefano D'Angelo, (Fri Feb 21, 3:04 pm)
Re: [LAD] JACK latency API clarifications, Paul Davis, (Fri Feb 21, 3:21 pm)
Re: [LAD] JACK latency API clarifications, Lieven Moors, (Fri Feb 21, 6:51 pm)
Re: [LAD] JACK latency API clarifications, Jörn Nettingsmeier, (Fri Feb 21, 7:34 pm)
Re: [LAD] JACK latency API clarifications, Lieven Moors, (Fri Feb 21, 8:28 pm)
Re: [LAD] JACK latency API clarifications, Fons Adriaensen, (Fri Feb 21, 8:01 pm)
Re: [LAD] JACK latency API clarifications, Stefano D'Angelo, (Fri Feb 21, 3:41 pm)