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 - 2:51 pm

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

On Fri, Feb 21, 2014 at 9:38 AM, Stefano D'Angelo wrote:

> Sorry guys, other two (silly?) questions:

The documentation does actually state which ones need to be RT, but there
is no list to easily consult.

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.

> 2. may the system sample rate actually change (while a client is running)?

JACK to date has never supported changing the sample rate.

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

On Fri, Feb 21, 2014 at 9:38 AM, Stefano D'Angelo <zanga.ma=
il@gmail.com
> wrote:
Sorry guys, other two (silly?) questions:

1. apart from the process callback, which callbacks need to be
RT-safe? Looking around I found a master thesis [1] that says: "Apart<=
br>
from
the JackProcessCallback callback, which is called in the realtime
audio thread for obvious reasons, all other callbacks are called
asynchronously in a specialized non-realtime thread, to avoid
notifications to interfere with audio processing", is that true?The documentation does actually state which =
ones need to be RT, but there is no list to easily consult.
The threading design described above is specific to Jack2. Jack1 deliv=
ers all callbacks to the same thread (which necessarily means that processi=
ng audio is blocked by other callbacks). This is one of the major (and larg=
ely hidden) design differences between Jack1 and Jack2.
=A0
2. may the system sample rate actually change (while a client is running)?<=
br>JACK to date has never supported changi=
ng the sample rate.=A0

--089e013cc30acb7c2b04f2ebc263--

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)