LAC 2009 - Paper: What's New in JACK2?

2009·2.1 MB·English

by  Stephane Letz

What’s new in JACK2?
St´ephane LETZ Nedko ARNAUDOV Romain MORET
Grame Sofia, PlayAll
Centre national de cr´eation musicale Bulgaria, France
France [email protected] [email protected]
[email protected]
Abstract • get installed internal clients and get/set all
their parameters.
JACK2 is the future JACK version based on the
C++ multi-processors Jackdmp version. This pa-
• get and set all server control parameters,
per presents recent developments: the D-Bus based
server control system, NetJack2 the redesigned net- start/stop the server.
work components for JACK and profiling tools de-
veloped during port on Solaris. The server side code is now compiled into
a libjackserver.so dynamic library that ex-
Keywords
ports the full client API as well as the
Audio server, D-Bus, real-time, networked audio, new control API. JACK clients can possi-
Solaris
bly be linked to the libjackserver.so library
and thus embed the JACK server in their
1 Introduction
process. For specific use cases, this can
JACK2 is the new JACK version based on
be especially interesting to create and dis-
the C++ multi-processor Jackdmp version [1].
tribute ”stand-alone” JACK applications. The
Jackdmp development started in 2005 with the
original jackd program as well as the new
goal to explore data-flow based scheduling of
jackdbus server control program (see section
the client graph on multi-cores machines. A 3.3) are linked to libjackserver.so. 2
re-design on the server core was necessary and
various improvements 1 have been implemented 2.0.2 Server internal clients
toremovesomelimitationsontheinitialmodel. Internal clients API has been slightly extended
D-Bus basedcontrolfortheserverappearedini- to allow Internal Clients to be configured
tially as a patch for JACK1 codebase. and loaded using the control API. Using the
Section 2 describes various internal build im- D-Bus server control access, internal clients can
provements in the code, section 3 presents the be easily activated. The new NetJack2 design
D-Bus services, section 4 describes NetJack2, (see section 4.2) is extensively using this model.
and section 5 new profiling tools developed dur-
ing the port on Solaris (Section 6). Additional 3 D-Bus access
developments are presented section 7 and ideas
D-Bus is an object model that provides IPC
for the future in section 8.
mechanism. D-Bus supports autoactivation of
2 Code restructuring objects, thus making it simple and reliable to
code a ”single instance” application or daemon,
Codehasbeenrestructuredformoreflexibleac-
and to launch applications and daemons on de-
cess to server side and client side code.
mand when their services are needed.
2.0.1 Control API on server side
A clean server control API has been defined to: 3.1 Improvements over classical
“jackd” approach
• get installed backend and get/set all their
• Simplified single thread model for con-
parameters.
trol and monitor applications. Various
D-Bus language bindings make it trivial to
1lock-free programming techniques for graph access,
”asynchronous/synchronous” server activation modes,
two threads model for audio and notifications process- 2All backend (dummy, alsa, coreaudio, OSS...) are
ing on client side... also linked to libjackserver.so
write control and monitor applications us- abstraction provides virtual tree of parameter
ing scripting languages like Python, Ruby, containers with container leaves that contain
Perl, etc.. parameters. Parameters are accessed using
simple addressing scheme (array of strings)
• A log file is available for inspection even
where address defines path to parameter, like
when autoactivation happens by the first
“drivers”, “alsa”, “dither”.
launched JACK application.
Overview of the tree of standard settings’ ad-
• A real configuration file is used to persist dresses:
settings to be manipulated through config-
• ”engine”
uration interface of JACK D-Bus object.
• ”engine”, ”driver”
• Improved graph inspection and control
mechanism. JACK graph is versioned. • ”engine”, ”realtime”
Connections, ports and clients have unique
• ”engine”, ...more engine parameters
(monotonically increasing) numeric IDs.
• ”driver”, ”device”
• High level abstraction of JACK settings.
Allows applications that can configure • ”driver”, ...more driver parameters
JACK to expose parameters that were not
• ”drivers”, ”alsa”, ”device”
known at compile (or tarball release) time.
Recent real world examples are the JACK • ”drivers”, ”alsa”, ...more alsa driver pa-
MIDI driver parameters and support for rameters
FFADO driver in QJackCtl. Upgrading of
• ”drivers”, ...more drivers
JACK requires upgrade of QJackCtl in or-
• ”internals”, ”netmanager”, ”multicast ip”
der to make new settings available in the
GUI. • ”internals”, ”netmanager”, ...more net-
manager parameters
3.2 How it works
• ”internals”, ...more internals
3.2.1 Autoactivation and
starting/stopping JACK server JACK settingsarepersisted. I.e. theyareau-
First, application that issues D-Bus method tomatically saved by jackdbus when they are
call to JACK controller object, causes set. Next time user starts JACK server, last
D-Bus session daemon to activate the ob- saved settings will be automatically used.
ject by starting the jackdbus executable. Changing JACK settings through the con-
Activating controller object does not start figure D-Bus interface takes effect on next
the server. Instead controller object has JACK server start. On the fly change of
several interfaces. The most important of the buffer size, as available in the libjack
them is the control interface. Control interface (jack.h) API, is also possible through the con-
contains methods for starting and stopping trol D-Bus interface.
JACK server, loading and unloading of internal
3.2.3 JACK parameter constraints
clients (netjack), setting buffer size and reset-
JACK internal modules that provide parame-
ting xrun counter. It also contains methods for
ters visible through control API can provide
querying information required by monitoring
information about parameter valid range (like
applications: whether JACK server is started,
realtime priority) or whether parameter should
whether JACK server is running in realtime
be presented as enumeration. Enumeration pa-
mode, sample rate, DSP load, current buffer
rameters can be strict and non-strict. Exam-
size, latency, xrun counter.
ple of strict enum parameter is dither parame-
JACK server autostart is achieved by lib-
ter of ALSA driver, it has only predefined valid
jack calling “jack server start” method of
values - “shaped noise”, “rectangular”, “trian-
JACK control D-Bus interface.
gualr” and “none”. Example of non-strict pa-
3.2.2 JACK settings rameter is device parameter of ALSA driver. It
Applications that want to manage isusefultoprovidesomedetecteddevicestrings
JACK settings can query and set all set- as choices to user, but still allow user to specify
tings that were traditionally specified as custom string that ALSA layer is supposed to
jackd command-line parameters. Interface understand.
3.2.4 JACK patchbay 3.4 Portability
In order to simplify patchbay applications, ex- While D-Bus implementations exist at least for
tended functionality is provided. There is a Windows and OSX platforms, D-Bus is not a
method that returns the current graph state. central part of their desktop environments and
Graph state has unique monotonically increas- thus using jackdbus on those operating sys-
ing version number and contains info about all tems will probably cause more problems than
clients, their ports and connections. Connec- it is supposed to solve.
tions,portsandclientshaveuniquenumericIDs
that are guaranteed not to be reused. Notifica- 4 NetJack2
tions about graph changes are provided using
4.1 Introduction
D-Bus signals.
NetJack2 is a feature allowing the use of
3.3 JACK D-Bus enabled applications JACK2 over a local network. It is not really
• JACK contains “jack control” executable a port of NetJack to JACK2 but can be seen
- a 300 lines of Python exposing like a refactoring of the main idea: send and re-
JACK D-Bus functionality. It allows ceive audio, midi or transport data over a net-
chained execution of several commands. work while staying in the Jack real-time audio
For example jack control ds alsa dps context. The differences between NetJack and
midi-driver raw eps realtime on NetJack2 are mainly about the global architec-
eps relatime-priority 70 start se- ture and network processing (how to slice data
lects ALSA driver, enables JACK MIDI into network packets and how to optimize the
raw backend, enables realtime mode, network bandwidth use).
sets realtime priority to 70 and starts
4.2 Architecture
JACK server.
NetJack2 isdesignedaroundaMaster/Slavear-
• LADI Tools is a set of programs to config- chitecture involving two components. The mas-
ure, control and monitor JACK . It pro- ter is an internal client (see Section 2.02) and
vides tray icon, Window Maker style dock- the slave is a classical JACK server running the
app, G15 keyboard LCD display integra- Net Backend. Those two components are built
tion application, configuration utility for as two dynamic libraries, netmanager.so and
managing JACK settings and log file mon- jack net.so(or.dllunderWindows),whichare
itor application. All tools are written in both linked with the main JACK server library.
Python. Thisarchitectureallowsseveralslavestobecap-
tured and running under a single master with-
• Patchage, the ubiquitous canvas modu-
out any other need of configuration.
lar patch bay can be compiled to use
D-Bus instead of libjack to communicate
• Master: the master is a classical
with JACK . Doing so also enables
JACK server, driven by an audio back-
JACK server start/stop functionality in
end (ALSA, CoreAudio, OSS or PortAu-
Patchage.
dio) and where an internal client called the
• LASH, recent developments of the audio NetManager is running. This NetManager
session handler by default use D-Bus to is just a ’logistical’ component which just
communicate with JACK . Various creates and removes classical JACK clients
JACK related features are planned: in the server as the Slaves appear and dis-
appear.
– Saving of JACK settings as part of
• Slave: theslaveisaclassicalJACK server,
“studio” session.
driven by the Net Backend. This specific
– Handling of “JACK server crash” backend isn’t controlling an audio device,
scenario: restarting JACK server, that means the backend’s read/write oper-
notifying JACK applications that ations aren’t executed on some audio hard-
JACK server reappeared so they ware, but on a network interface (wireless
can reconnect to it, and restoring is not supported because it doesn’t really
JACK connections. offer real-time networking capabilities).
4.2.1 Multicast communications and those constraints to keep a real-time transmis-
NetManager sion means compromises.
NetJack2 is based upon the principle that two First, we can’t afford a total secured trans-
computers must be able to ’connect’ themselves mission, usingsecuredprotocolsuchasTCPfor
without knowing the parameters by advance. instance. TCP can not be used as a real-time
In NetJack2 , slaves are fully configured by the protocolbecauseitinvolvesacknowledgmentfor
master. The global initialization process is thus each sent packet, automatic re-emission in case
quite simple: of packet loss, what automatically discard such
a protocol for a true real-time audio transmis-
1. The slave starts multicasting it’s availabil- sion. That’s why NetJack2 uses a very simple
ity on the network by communicating its way to exchange streams: the UDP protocol.
capabilities (number of available channels) NetJack2 main principle is very simple, so the
to anyone who wants to hear it best way to handle it is to choose a quite low
level layer of network communication protocols,
2. The master catches the message and gives
and just add the few things we need to it. By
back to the slave a full set of parameters
usingUDP,wejustgetaverysimpleandhighly
(samplerate, backend buffer size...)
configurable way to exchange data.
3. The slave receives it and starts the stream
The second main aspect is to consider time.
exchange
In a network transmission, transmission delays
4. Bi-directional communication is now run- are reflected by the bandwidth notion. The
ning, and the slave is fully synched on the bandwidth is the amount of data we can trans-
master’s incoming network stream mit in a certain amount of time. For real-time
transmission, that means the higher the band-
Lets see how this exchange begins... widthis, thequickestwereceiveourdataonthe
distant computer. Increasing bandwidth means
Multicast communications This first ini-
reducing transmission delay. That principle is
tialization step is done over a Multicast group,
very simple and linear: a gigabyte networking
thus the slave doesn’t have to know the mas-
infrastructure is ten time faster than a 100mb
ter’s address, or even configuration. A newly
network. The bandwidth use optimization ap-
incoming slave just has to send its ’availability’
pears as a major aspect to take care of. That’s
message to the Multicast group, and if a mas-
why NetJack2 splits data into packets that are
ter is listening to this Multicast group, it will
maximum sized (the maximum size of a packet
automatically starts the transmission.
is given by the network MTU). Dealing with
NetManager component The NetManager
larger packets increase the network’s speed use,
component is dealing with the initialization
but it also minimizes packets losses.
phase. TheNetManagerdoesn’tmanipulateau-
The third aspect of real-time networking is
dio or midi signals, it just listens to the Multi-
the fact that a network has a very random-
cast group and creates or destroy Masters as
ized timing behavior, which is not only depend-
Slaves come and go. This component is seen
ing on the two connected computers. Routers,
by JACK as an internal client, that means this
firewalls and other networking devices add ran-
client is loaded in the JACK server context,
dom unpredictable transmission delay. In real-
using the specifically designed API and util-
time audio, we can’t wait longer than a given
ity (jack load executable). But it can also be
amount of time (one audio cycle for example).
loadedandmanagedbythejack controlsystem.
NetJack2 extensively use the timeout notion on
4.3 Real-time networking all its internal networking transmission. If we
consider we can’t wait for data over than a cy-
NetJack2 Provides real-time network capabili-
cle length, the best way to keep synced in time
ties. Audio (or midi or transport) data use net-
is to skip data that were not received on time.
work streams as if those streams were classical
’jackified’ applications. The main difficulty of
4.4 Network modes and latency
such a concept is to handle real-time network-
ing. Connecting two computers in a simple net- NetJack2 doesn’t have one only functional
work implies some constraints: packets losses, mode. Itactuallyhasthree’networking’modes:
random transmission delay, routing issues, dis- fast, normal and slow. What those modes con-
connection timeout management etc. Reducing trol is in fact the total time latency the network
will add. The use of one mode or another is in • only a few channel to exchange on a fast
fact depending on what the user wants to do. network, the fast mode can be very pleas-
ant because it doesn’t add extra-latency
4.4.1 Fast mode
In fast mode, the whole system (composed by • normal use of the network (up to 48 chan-
the two connected computers) will not add ex- nelsat48kHzona100mbnetwork),normal
tra latency. In a cycle number n, the mas- modewillguaranteeaverysmallamountof
ter will send its data, the slave is supposed packet loss (probably no loss if the network
to receive it, produce its own data, and send is stable)
it back to the master in the same cycle. Ev-
• huge use of network and processing: the
erything happens just as if the slave was a
slow mode is the most ’secured’ (the mas-
classical JACK client plugged into the master’s
ter doesn’t wait for the slave’s return data
JACK server. The fast mode is designed for
before two cycles, giving the slave the net-
fast network, with a small amount of data to
work the time to transport data and the
exchange (only a few audio channels for ex-
slave the time to process it)
ample), and a small amount of processing on
the slave’side, because data are expected in the 4.5 Measurements
same audio cycle (that means we consider the
JACK can be compiled with the possibility of
network transmission time to be significantly
monitoring NetJack2 networking activity, thus
less than the cycle length). The fast mode can
allowing accurate measurements about what’s
bequiteunstablebecauseitusesalongtimeout,
going on between the master and the slave.
allowing NetJack2 to use 100% of the available
Those measurements are a pretty good way to
CPU time.
understand what is behind the different avail-
4.4.2 Normal mode able networking modes.
The normal mode takes into account the net- This profiling system keeps a track of sev-
work, and add one extra-latency cycle, corre- eral timings, and the results can be exploited to
sponding to the use of the full available band- get an approximation of NetJack2 ’s CPU con-
width. The master send its data in the current sumption.
ncycle,andexpectreturndatafromtheslavein Becausethosemeasurementsarequiteuneasy
the n+1 cycle. Don’t forget the slave is a back- to dissect and explain, more explanation will be
end, and as a backend, it has two ’processing’ available on the JACK wiki.
modes: syncorasync. Thus,inasyncmode,the
4.6 Adapters components
slave will send the previous ’n-1’ cycle data just
after receiving the current n cycle. That means Adapters components allow to adapt the net-
in this mode (async), we just don’t take into work stream synced on the master machine
account the slave’s processing time and data clock, in order to be played on the slave ma-
are sent with no additional delay. The normal chine.
mode use a small timeout, considering data has 4.6.1 AudioAdapter
to be available very quickly (because of the ex- When the slave machine is using the Net Back-
tra latency cycle). This mode doesn’t ’block’ end and if the user wants to listen to the net-
JACK processing while waiting for data. work stream on the slave audio card, the net-
4.4.3 Slow mode work stream has to be ”adapted”, since the two
The slow mode adds two extra-latency cycles. audio cards may run at different buffer size,
This mode has been introduced for an exten- sample rate and their clocks are typically not
sive use of the network with a lot of processing synchronized. This is done using an in server
running on the slave. It can be very useful in client called audioadapter, which ajust the mas-
a multitrack production context, because trans- ter sample rate and buffer size to the slave
port (play/stop, position), which is also sent in audio card sample rate and buffer size. Au-
NetJack2 ,includeslatencymanagement,sothe dioadapter components are using an interme-
whole network will start ’simultaneously’ (that diate ring-buffer and the libsamplerate library
meansthe’fastest’JACK clientwillstartinthe 3 to resampled the stream when needed. They
cycle within which all data are available. have beendeveloped on eachplatform usingthe
availablenativeaudioAPI:CoreAudioonOSX,
4.4.4 Conclusion
We can resume those three mode quite simply: 3http://www.mega-nerd.com/SRC/
ALSA on Linux, PortAudio on Window and Audio driver timing
1370
OSS an Solaris. Audio period
1360
4.6.2 NetAdapter
1350
When the slave machine is using a regular au-
1340
diobackendandiftheuserstillwantstoreceive usec 1330
a stream from the network, the netadapter in
1320
server client can be used. This component has
1310
basically the same behaviour as the Net Back-
1300
end but also adapt the master sample rate and
1290
0 5000 10000 15000 20000 25000 30000 35000 40000 45000 50000
buffer size to the possibly different slave audio audio cycles
card sample rate and buffer size.
Figure 1: Audio driver interrupt, at 48 kHz and
4.7 NetJack2 conclusion 64 frames, average is 1333 usec, interrupt pe-
NetJack2 is an easy way to exchange audio, riod is regular, with small variations of about
midi or transport control data over a network +/- 30 usec. (Vertical axis shows duration in
in a realtime context. This component is work- usec and horizontal axis the number of audio
ing so far, and it will be improved in the future. cycles.)
NetJack2 is currently available with JACK2 ,
and a few documentation can be found on the
JACK wiki4. Audio driver timing
2800
Audio period
2600
5 Profiling tools
2400
Timing measurements allow developers to
2200
help understanding the behaviour of their usec 2000
JACK basedapplications. Theservercodebase
1800
now allows to record various timing while the
1600
server and clients are running and generates
1400
scripts to interpret them.
1200
0 200 400 600 800 1000 1200 1400 1600
While running, timestamps are taken for the audio cycles
server and running clients: wake-up date of au-
Figure 2: Audio driver interrupt, at 44.1 kHz
dio driver, activation, actual wake-up and end
and 64 frames, average is 1451 usec, but inter-
date of each running client. Client schedul-
rupt period is not regular
ing latency and duration are also computed.
They are saved as a JackEngineProfiling.log
file containing time points when the server is
closed. Scripts for Gnuplot are also gener- the audio cycle is composed of: read audio in-
ated. Use the command: gnuplot -persist put buffers, write audio output buffers computed
Timing1.plot with Timing1.plot up to Tim- at previous cycle, execute the graph. When the
ing5.plot. The scripts also generate PDF files. interruptperiodisregular,thentheserverasyn-
A jack profiler internal client allows to see chronous mode can be safely used (fig 1). On
all measures as audio signals to be analyzed or thecontraryanonregulardriverinterruptforce
recorded with additional tools. to synchronous mode to be chosen (otherwise
the graph may lack time to finish its execution
5.1 Audio driver interrupts
if duration between 2 consecutive interrupts is
Timing1.plot allows to display the audio driver too short) (fig 2).
timing, that is the duration between consecu-
5.2 Driver end date
tives interrupts.
The JACK2 server can run in two different Timing2.plot allows to display the audio driver
graph scheduling mode: in synchronous mode, end date. This measure is interesting to distin-
theaudiocycleiscomposedof: read audio input guish what happens in server synchronous ver-
buffers, execute the graph, write audio output sus asynchronous mode. In synchronous mode,
buffers. In asynchronous mode on the contrary, the driver end date takes the graph execution
duration in account (fig 3). 5 In asynchronous
4trac.jackaudio.org/wiki/WalkThrough/User/
NetJack2 5The graph here shows several clients launched one
Driver end date Clients end date
1400 1400
Driver end date Audio period
jack_simple_client
1200 1200 etheerthsoenrsiko-n0i1k
ethersonik-02
ethersonik-03
1000 1000 ethersonik-04
ethersonik-05
ethersonik-06
800 800 eetthheerrssoonniikk--0078
usec usec ethersonik-09
600 600
400 400
200 200
0 0
0 5000 10000 15000 20000 25000 30000 35000 40000 45000 50000 0 5000 10000 15000 20000 25000 30000 35000 40000 45000 50000
audio cycles audio cycles
Figure 3: Driver end date when the server runs Figure 5: Clients end date
in synchronous mode: the date raises each time
a new client is launched.
Clients scheduling
500
jack_simple_client
Driver end date 450 eetthheeerrthssooennrsiikko--n00i12k
180 400 ethersonik-03
Driver end date ethersonik-04
160 350 eetthheerrssoonniikk--0056
ethersonik-07
140 300 eetthheerrssoonniikk--0089
120 usec 250
200
100
usec 80 150
100
60
50
40 0
0 5000 10000 15000 20000 25000 30000 35000 40000 45000 50000
20 audio cycles
0
0 10000 20000 30000 40000 50000 60000 70000
audio cycles Figure 6: Clients scheduling latency
Figure 4: Driver end date when the server
runs in asynchronous mode: the date stay ap-
proximatively constant when new clients are real-time thread becomes runnable, the global
launched, since it only depends of cumulated scheduling latency depends on the fact a core
read and write durations. is effectively available in the machine and the
actual OS scheduling latency. Thus this value
obviously depends of the topology of the graph
mode, the driver does not wait for the graph and number of available cores on the machines
end, but returns immediately after the write on a given setup. To precisely measure the OS
step. Thus the driver end date measures the scheduling latency only, the best is to have a
read audio input buffers, write audio output number of clients that is less than the number
buffers parts only (fig 4). of available cores (fig 6).
5.3 Clients end date 5.5 Clients duration
Timing3.plot allows to display the audio driver
timingandallclientsenddate. Thiscurvegives Clients duration
350
a global view of all clients DSP use. The audio jack_simepthlee_rcsloiennikt
interruptdurationisdisplayedaswellastheend 300 eeettthhheeerrrsssooonnniiikkk---000123
ethersonik-04
date of all running clients. The system works 250 eetthheerrssoonniikk--0056
ethersonik-07
correctly if the end date of the last client is still 200 eetthheerrssoonniikk--0089
below the audio interrupt duration (fig 5). usec
150
5.4 Clients scheduling latency 100
Timing4.plotallowstodisplayallclientschedul- 50
ing latencies (difference between activation and 0
0 5000 10000 15000 20000 25000 30000 35000 40000 45000 50000
actual wake-up dates). When the application audio cycles
Figure 7: Clients duration
by one, the driver end date then raise after each new
client is started.
Timing5.plot allows to display all client du- been done on a Dell XPS 420 Intel 4 cores ma-
ration (difference between end date and actual chine running Solaris 10 and using the inter-
wake-up date) (fig 7). nal HD Audio card using OSS 4.0 version. Fig
1 shows the audio driver interrupts when the
5.6 Real-time measurements
server is running using a 64 frames buffer size
The jack profiler internal client allows to
at 48 kHz, in synchronous mode and using the
see all measures as audio signals. It can be
highestschedulingprioritythatcanbeobtained
loaded at anytime using the jack load tool.
(usingthefollowingcommand: jackd -R -S -P
JACK output ports will be created and con-
59 -d oss -p 64). Then fig 2 to 5 shows the
taintimingmeasuresconvertedinaudiosignals.
different curves obtained with a highly loaded
At each audio cycle, the measured value is re-
machine. Using the profiling tools we were able
calibrated to be in the [-1,1] range and copied
to conclude that:
into the audio buffer (same value for the entire
cycle). Three general output JACK ports can
• It appears that the OSS driver does not
be added (respectively using the -c, -p, -e pa-
guaranty a perfectly regular audio inter-
rameters in the jack load parameter line):
rupt period, depending of the driver set-
tings. Thus the synchronous (-S) mode
• profiler:cpu load: is the DSP CPU load
should be preferably chosen when starting
between 0 and 1.
the server.
• profiler:driver period: is the driver pe-
• Solaris defines several scheduling classes.
riod variation expressed at the difference
The Real-Time scheduling class goes from
between the actual driver period and the
100 to 159 on a global 0 to 169 scale. The
expecteddriverperiod, thendividedbythe
corresponding POSIX priority to be set in
expected driver period, between -1 and 1.
JACK will go from 0 to 59 (-P59 for high-
• profiler:driver end time: is the driver est priority).
end time expressed as driver end time di-
• TheSolarishasquitegoodReal-Timecapa-
vided by the driver period, between 0 and
bilities[2], andwefoundthatusingProces-
1.
sor sets allows to decrease the RT threads
For each running client, two additional scheduling latencies and have a more pre-
JACK ports will appear: dictable system. We measured a maximum
scheduling latency of 80 usec in this config-
• profiler:”client name”:scheduling: is uration.
the client scheduling duration expressed
as the scheduling duration divided by the 7 Additional developments
driver period, between 0 and 1.
7.1 Better Windows port
• profiler:”client name”:duration: isthe On Windows, the JACK code base was ini-
clientdurationexpressedastheclientdura- tially compiled using Microsoft VC++ tools.
tion divided by the driver period, between All projects have been converted to use the free
0 and 1. CodeBlock and MinGW 6 environments.
6 Solaris port 7.2 Testing and debugging tools
The french radio RTL aims at developing it’s Different tools have been implemented to help
future digital radio using a JACK based sys- developers when coding JACK based applica-
tem,hostingasetofaudioapplications: playlist tions. Profilingtoolshasalreadybeenpresented
manager, audio effects (compressor...), real- in section 5. Two more are available:
timesignalanalysiscomponents(speakerrecog-
7.2.1 Checking JACK API
nition for instance), encoding and web broad-
The correctness of JACK API can be tested us-
casting... on a Solaris system, when most of
ing jack test tool. This program will open
their audio files data base management tools
JACK clients, test various aspects of the API:
are already running. The timing measurements
registering ports, setting callbacks, activating
tools have been developed to characterize the
the client... Real-time communication between
real-time behaviour of this system in several
setups. The set of curves in this paper have 6see www.codeblocks.org and www.mingw.org
two clients is also tested as well as Transport References
API.
[1] Stephane Letz, Dominique Fober, and Yann
7.2.2 Checking use of JACK API Orlarey. jackdmp: Jack server for multi-
processor machines. Linux Audio Confer-
When launching JACK applications, a
ence, 2005.
JACK CLIENT DEBUG environment
variable can be set 7 to launch the client in [2] J Litchfield. Real-time in the Op-
debug mode: all calls to the API are traced erating Environment Solaris 8.
and a log file is generated. Correct use of the http://www.opengroup.org/rtforum/oct2000
API will be checked (opened clients should be /slides/litchfield.pdf, 2008.
closed, activated clients should be deactivated,
port registration/unregistration matches is
verified...)
8 Blue sky for singing penguins
living on the planet JACK
The future could (and probably should) try to
solve some problems that are getting bigger
with increasing popularity of JACK :
• There can be better handling of misbe-
having JACK clients. Is it wise to allow
clients to change parameters that will dis-
rupt JACK operation? Today, obnoxious
clients auto-connect without allowing con-
figuration. Tomorrow, what if a client
thinks it must reset the sample rate or the
period size because of cutting corners in
the dsp code? The Access Control Lists
(ACL) looks like obvious and traditional
solution but applying it to JACK domain
may lead to quite complex implementation
because of authentication that needs to
preceedevensimplestauthorizationchecks.
• Developing a control application based on
OSC could be quite interesting, allowing
access and control of any JACK server on
the network.
• MIDI backends: interfacing JACK MIDI
with the native MIDI API on each plar-
fom (CoreMidi on OSX, ALSA Midi on
Linux and WinMME on Windows) has to
be done.
9 Acknowledgements
Juuso Alasuutari has significally contributed to
jackdbus for JACK1 and Marc-Olivier Barre
contributedtojackdbus bymakingituseXDG
compliant directories.
Work on profiling tools and Solaris port has
beenfundedbyRTLfrenchradio(EDIRADIO).
7using ”export JACK CLIENT DEBUG = on”