Low-Latency Audio on Linuxby Means of Real-Time Scheduling ∗

Tommaso CUCINOTTA and Dario FAGGIOLI and Giacomo BAGNOLIScuola Superiore Sant’Anna

Via G. Moruzzi 1, 56124, Pisa (Italy){t.cucinotta, d.faggioli}@sssup.it, g.bagnoli@asidev.com

Abstract

In this paper, we propose to use resource reserva-

tions scheduling and feedback-based allocation tech-

niques for the provisioning of proper timeliness guar-

antees to audio processing applications. This al-

lows real-time audio tasks to meet the tight tim-

ing constraints characterizing them, even if other in-

teractive activities are present in the system. The

JACK sound infrastructure has been modified, lever-

aging the real-time scheduler present in the Adaptive

Quality of Service Architecture (AQuoSA). The ef-

fectiveness of the proposed approach, which does not

require any modifiction to existing JACK clients, is

validated through extensive experiments under dif-

ferent load conditions.

Keywords

JACK, real-time, scheduling, time-sensitive, re-

source reservation

1 Introduction and Related Work

There is an increasing interest in consideringGeneral Purpose Operating Systems (GPOSes)in the context of real-time and multimedia ap-plications. In the Personal Computing domain,multimedia sharing, playback and processing re-quires more and more mechanisms allowing forlow and predictable latencies even in presenceof background workloads nearly saturating theavailable resources, e.g., network links and CPUpower. In the professional multimedia domain,spotting on stages, it is becoming quite commonto see a digital keyboard attached to a commonlaptop running GNU/Linux. DJs and VJs aremoving to computer based setups to the pointthat mixing consoles have turned from big decksinto simple personal computers, only containing

∗ The research leading to these results has received fund-ing from the European Community’s Seventh FrameworkProgramme FP7 under grant agreement n.214777 “IR-MOS – Interactive Realtime Multimedia Applications onService Oriented Infrastructures” and n.248465 “S(o)OS– Service-oriented Operating Systems.”

audio collections and running the proper mixingsoftware.

In fact, developing complex multimedia appli-cations on GNU/Linux allows for the exploita-tion of a multitude of OS services (e.g., network-ing), libraries (e.g., sophisticated multimediacompression libraries) and media/storage sup-port (e.g., memory cards), as well as comfort-able and easy-to-use programming and debug-ging tools. However, contrarily to a Real-TimeOperating System (RTOS), a GPOS is not gen-erally designed to provide scheduling guaranteesto the running applications. This is why eitherlarge amount of buffering is very likely to oc-cur, with an unavoidable impact on responsetime and latencies, or the POSIX fixed-priority(e.g., SCHED FIFO) real-time scheduling is uti-lized, but this turns out to be difficult whenthere is more than one time-sensitive applica-tion in the system. Though, on a nowadaysGNU/Linux system, we may easily find a vari-ety of applications with tight timing constraintsthat might benefit from precise scheduling guar-antees, in order to provide near-professionalquality of the user experience, e.g., audio acqui-sition and playback, multimedia (video, gaming,etc.) display, video acquisition (v4l2), just tocite a few of them. In such a challenging sce-nario in which we can easily find a few tens ofthreads of execution with potentially tight real-time requirements, an accurate set-up of real-time priorities may easily become cumbersome,especially for the user of the system, who is usu-ally left alone with such critical decisions as set-ting the real-time priority of a multimedia task.

More advanced scheduling services than justpriority based ones have been made available forLinux during the latest years, among the othersby [Palopoli et al., 2009; Faggioli et al., 2009;Checconi et al., 2009; Anderson and Students,2006; Kato et al., 2010]. Such scheduling poli-cies are based on a clear specification that needsto be made by the application about what is the

computing power it needs and with what timegranularity (determining the latency), and thisscheme is referred to as resource reservations.This is usually done in terms of a reservationbudget of time units to be guaranteed every pe-riod. The reservation period may easily be setequal to the minimum activation period of theapplication. Identifying the reservation budgetmay be a more involved task, due to the need fora proper benchmarking phase of the application,and it is even worse in case of applications withsignificant fluctuations of the workload (such asit often happens in multimedia ones). Rather,it is more convenient to engage adaptive reser-vation scheduling policies, where the schedul-ing parameters are dynamically changed at run-time by an application-level control-loop. Thisacts by monitoring some application-level met-rics and increasing or decreasing the amount ofallocated computing resources depending on theinstantaneous application workload. Some ap-proaches of this kind are constituted by [Segoviaet al., 2010; Abeni et al., 2005; Nahrstedt et al.,1998], just to mention a few.

1.1 Contribution of This Paper

This work focuses on how to provide enhancedtimeliness guarantees to low-latency real-timeaudio applications on GNU/Linux. We useadaptive reservations within the JACK au-dio framework, i.e., we show how we modi-fied JACK in order to take advantage of AQu-oSA [Palopoli et al., 2009], a software architec-ture we developed for enriching the Linux kernelwith resource reservation scheduling and adap-tive reservations. Notably, in the proposed ar-chitecture, JACK needs to be patched, but au-dio applications using it do not require to bemodified nor recompiled. We believe the discus-sion reported in this paper constitutes a valu-able first-hand experience on how it is possibleto integrate real-time scheduling policies intomultimedia applications on a GPOS.

2 JACK: Jack Audio Connection Kit

JACK 1 is a well-known low-latency audioserver for POSIX conforming OSes (includingLinux) aiming at providing an IPC infrastruc-ture for audio processing where sound streamsmay traverse multiple independent processesrunning on the platform. Typical applications— i.e., clients — are audio effects, synthesis-

1Note that the version 2 of JACK is used for thisstudy

ers, samplers, tuners, and many others. Theseclients run as independent system processes, butthey all must have an audio processing threadhandling the specific computation they make onthe audio stream in real-time, and using theJACK API for data exchanging.

On its hand, JACK is in direct contact withthe audio infrastructure of the OS (i.e., ALSAon Linux) by means of a component referred toas (from now on) the JACK driver or just thedriver. By default, double-buffering is used, sothe JACK infrastructure is required to processaudio data and filling a buffer, while the under-lying hardware is playing the other one. Eachtime a new buffer is not yet available in time,JACK logs the occurrence of an xrun event.

3 AQuoSA Resource ReservationFramework

The Adaptive Quality of Service Architec-ture (AQuoSA2) is an open-source frame-work enabling soft real-time capabilities andQoS support in the Linux kernel. It in-cludes: an deadline-based real-time sched-uler; temporal encapsulation provided via theCBS [Abeni and Buttazzo, 1998] algorithm; var-ious adaptive reservation strategies for buildingfeedback-based scheduling control loops [Abeniet al., 2005]; reclamation of unused bandwidththrough the SHRUB [Palopoli et al., 2008] al-gorithm; a simple hierarchical scheduling capa-bility which allows for Round Robin schedul-ing of multiple tasks inside the same reser-vation; a well-designed admission-control log-ics [Palopoli et al., 2009] allowing controlled ac-cess to real-time scheduling capabilities of thesystem for unprivileged applications. For moredetails about AQuoSA, the reader is referredto [Palopoli et al., 2009].

4 Integrating JACK with AQuoSA

Adaptive reservations have been applied toJACK as follows. In JACK, an entire graphof end-to-end computations is activated witha periodicity equal to buffersize

samplerate and it must

complete within the same period. Therefore, areservation is created at the start-up of JACK,and all of the JACK clients, comprising the real-time threads of the JACK server itself (the au-dio “drivers”), have been attached to such reser-vation, exploiting the hierarchical capability ofAQuoSA. The reservation period has been set

2More information is available at: http://aquosa.sourceforge.net.

equal to the period of the JACK work-flow acti-vation. The reservation budget needs thereforeto be sufficiently large so as to allow for com-pletion of all of the JACK clients within the pe-riod, i.e., if the JACK graph comprises n clients,the execution time needed by all of the JACKclients are c1, . . . cn, and the JACK period isT , then the reservation will have the followingbudget Q and period P :Q =

∑ni=1 ci

P = T(1)

Beside this, an AQuoSA QoS control-loopwas used for controlling the reservation budget,based on the monitoring of the budget actu-ally consumed at each JACK cycle. The per-centile estimator used for setting the budget isbased on a moving window of a configurablenumber of consumed budget figures observed inpast JACK cycles, and it is tuned to estimatea configurable percentile of the consumed bud-get distribution (such value needs to be suffi-ciently close to 100%). However, the actual allo-cated budget is increased with respect to the re-sults of this estimation by a (configurable) over-provisioning factor, since there are events thatcan disturb the predictor, making it potentiallyconsider inconsistent samples, and thus nullifyall the effort of adding QoS support to JACK, ifnot properly addressed. Examples are an xrunevent and the activation of a new client, sincein such case no guess can be made about theamount of budget it will need. In both cases, thebudget is bumped up by a (configurable) per-centage, allowing the predictor to reconstructits queue using meaningful samples.

4.1 Implementation Details

All the AQuoSA related code is contained inthe JackAquosaController class. The oper-ations of creating and deleting the AQuoSAreservation are handled by the class construc-tor and destructor, while operations necessaryfor feedback scheduling — i.e., collect the mea-surements about used budget, managing thesamples in the queue of the predictor, setnew budget values, etc. — are done by theCycleBegin method, called once per cycle inthe real-time thread of the server. Also, theJackPosixThread class needed some modifica-tions, in order to attach real-time threads to theAQuoSA reservation when a new client registerswith JACK, and perform the corresponding de-tach operation on a client termination.

The per-cycle consumed CPU time valueswere used to feed the AQuoSA predictor andapply the control algorithm to adjust the reser-vation budget.

5 Experimental Results

The proposed modifications to JACK havebeen validated through an extensive experi-mental evaluation conducted over the imple-mented modified JACK running on a Linux sys-tem. All experiments have been performed ona common consumer PC (Intel(R) E8400@3.00GHz) with CPU dynamic voltage-scaling dis-abled, and with a Terratec EWX24/96 PCIsound card. The modified JACK frameworkand all the tools needed in order to reproducethe experiments presented in this section areavailable on-line 3.

In all the conducted experiments, results havebeen gathered while scheduling JACK usingvarious scheduling policies:

• CFS: the default Linux scheduling policy forbest effort tasks;

• FIFO: the Linux fixed priority real-timescheduler;

• AQuoSA: the AQuoSA resource reservationscheduler, without reclaiming capabilities;

• SHRUB: the AQuoSA resource reservationscheduler with reclaiming capabilities.

The metrics that have been measuredthroughout the experiments are the following:

• audio driver timing: the time intervalbetween two consecutive activations of theJACK driver. Ideally it should look like anhorizontal line corresponding to the value:buffersizesamplerate ;

• driver end date: the time interval be-tween the start of a cycle and the instantwhen the driver finishes writing the pro-cessed data into the sound card buffer. Ifthis is longer than the server period, thenan xrun just happened.

When the AQuoSA framework is used to pro-vide QoS guarantees, we also monitored the fol-lowing values:

• Set budget (Set Q): the budget dynam-ically set for the resource reservation dedi-cated to the JACK real-time threads;

3http://retis.sssup.it/~tommaso/papers/lac11/

• Predicted budget (Predicted Q): thevalue predicted at each cycle for the budgetby the feedback mechanism;

Moreover, the CPU Time used, at each cycle,by JACK and all its clients has been measuredas well. If AQuoSA is used and such value isgreater than the Set Q, then an xrun occurs (un-less the SHRUB reclaiming strategy is enabled).

First of all the audio driver timing in a config-uration where no clients were attached to JACKhas been measured, and results are shown in Ta-ble 1. JACK was using a buffer-size of 128 sam-ples and a sample-rate of 96 kHz, resulting in aperiod of 1333µs. Since, in this case, no otheractivities were running concurrently (and sincethe system load was being kept as low as possi-ble), the statistics reveal a correct behaviour ofall the tested scheduling strategies, with CFS ex-hibiting the highest variability, as it could havebeen expected.

Table 1: Audio driver timing of JACK with noclients using the 4 different schedulers (valuesare in µs).

Min Max Average Std. DevCFS 1268 1555 1342.769 3.028FIFO 1243 1423 1333.268 2.421AQuoSA 1279 1389 1333.268 2.704SHRUB 1275 1344 1333.268 2.692

5.1 Concurrent Experiments

To investigate the benefits of using reserva-tions to isolate the behaviour of different —concurrently running— real-time applications,a periodic task simulating the behaviour of atypical real-time application has been added tothe system. The program is called rt-app, andit is able to execute for a configurable amountof time over some configurable period.

The scheduling policy and configuration usedfor JACK and for the rt-app instance in theexperiments shown below are given in Table 2.

In all of the following experiments, we used a“fake” JACK client, dnl, constituted by a sim-ple loop taking about 7% of the CPU for itscomputations. The audio processing pipelineof JACK is made up of 10 dnl clients, addedone after the other. This leads to a total of75% CPU utilisation. When AQuoSA is used(i.e., in cases (4) and (5)), JACK and all itsclients share the same reservation, the budget ofwhich is decided as described in Section 4. Con-cerning rt-app, when it is scheduled by AQuoSA

Table 2: Scheduling policy and priority (whereapplicable) of JACK and rt-app in the experi-ments in this section

scheduling class priorityJACK rt-app JACK rt-app

(1) CFS CFS – –(2) FIFO FIFO 10 15(3) FIFO FIFO 10 5(4) AQuoSA AQuoSA – –(5) SHRUB SHRUB – –

or SHRUB, the reservation period is set equalto the application period, while the budget isslightly over-provisioned with respect to its ex-ecution time (5%). Each experiment was runfor 1 minute.

5.1.1 JACK with a period of 1333µsand video-player alike load

In this experiment, JACK is configured witha sample-rate of 96 kHz and a buffer-size of128 samples, resulting in an activation period of1333µs, while rt-app has period of 40ms andexecution time of 5ms. This configuration forrt-app makes it resemble the typical workloadproduced by a video (e.g., MPEG format) de-coder/player, displaying a video at 25 framesper second.

Figures 1a and 1b show the performance ofJACK, in terms of driver end time, and ofrt-app, in terms of response time, respectively.Horizontal lines at 1333µs and at 40ms arethe deadlines. The best effort Linux schedulermanages to keep the JACK performance good,but rt-app undergoes increased response-timesand exhibits deadline misses in correspondenceof the start and termination of JACK clients.This is due to the lack of true temporal isola-tion between the applications (rather, the LinuxCFS aims to be as fair as possible), that causesrt-app to miss some deadlines when JACK haspeaks of computation times. The Linux fixed-priority real-time scheduler is able to correctlysupport both applications, but only if their rel-ative priorities are correctly set, as shown byinsets 2 and 3 (according to the well-knownrate-monotonic assignment, in this case rt-appshould have lower priority than JACK). Onthe contrary, when using AQuoSA (inset 4), weachieve acceptable response-times for both ap-plications: rt-app keeps its finishing time wellbelow its deadline, whilst the JACK pipelinehas sporadic terminations slightly beyond thedeadline, in correspondence of the registration

0

200

400

600

800

1000

1200

1400

0 10000 20000 30000 40000 0 10000 20000 30000 40000 0 10000 20000 30000 40000 0 10000 20000 30000 40000 0 10000 20000 30000 40000

(1) CFS/CFS (2) FIFO/FIFO (3) FIFO/FIFO (4) AQuoSA/AQuoSA (5) SHRUB/SHRUB

(a)

0

10000

20000

30000

40000

50000

60000

70000

80000

0 500 1000 1500 0 500 1000 1500 0 500 1000 1500 0 500 1000 1500 0 500 1000 1500

(b)

0

200

400

600

800

1000

1200

1400

0 10000 20000 30000 40000 0 10000 20000 30000 40000 0 10000 20000 30000 40000 0 10000 20000 30000 40000 0 10000 20000 30000 40000

CPU TimePredicted Q

Set Q

(c)

Figure 1: Driver end time of JACK (a) and response-times of rt-app (b). The Y axis reportstime values in µs, while the X axis reports the application period (activation) number. The variousinsets report results of the experiment run under configurations (1), (2), (3), (4) and (5), from leftto right, as detailed in Table 2. In (c), we report the CPU Time and (in insets 4 and 5) the set andpredicted budgets for JACK during the experiment.

of the first few clients. This is due to the over-provisioning and the budget pump-up heuristicswhich would benefit of a slight increase in thoseoccasions (a comparison of different heuristics isplanned as future work). However, it is worthmentioning that the JACK performance in thiscase is basically dependent on itself only, andcan be studied in isolation, independently ofwhat else is running on the system. Finally,when enabling reclaiming of the unused band-width via SHRUB (inset 5), the slight budgetshortages are compensated by the reclaimingstrategy: the small budget residuals which re-main unused by one of the real-time applica-tions at each cycle are immediately reused bythe other, if needed.

For the sake of completeness, Figure 1c showsthe CPU Time and, for the configurations us-

ing AQuoSA, the Set Q and Predicted Q valuesfor the experiment. The figure highlights thatthe over-provisioning made with a high overallJACK utilisation is probably excessive with thecurrent heuristic, so we are working to improveit.

5.1.2 JACK with a period of 2666µsand VoIP alike load

Another experiment, very similar to the pre-vious one but with slightly varied parametersfor the two applications has been run. Thistime JACK has a sample-rate of 48kHz and abuffer-size of 128 samples, resulting in a periodof 2666µs, while rt-app has a period of 10msand an execution time of 1.7ms. This could berepresentative of a VoIP application, or of a 100Hz video player.

Results are reported in Figure 5. Observa-tions similar to the ones made for the previousexperiment may be done. However, the inter-ferences between the two applications are muchmore evident, because the periods are closer toeach other than in the previous case. Moreover,the benefits of the reclaiming logic provided bySHRUB appears more evident here, since usingjust a classical hard reservation strategy (e.g.,the hard CBS implemented by AQuoSA on the4th insets) is not enough to guarantee correctbehaviour and avoid deadline misses under thehighest system load conditions (when all of thednl clients are active).

Figure 2: Server period and clients end time ofJACK with minimum latency scheduled by CFS.

Figure 3: Server period and clients end timeof JACK with minimum possible latency sched-uled by FIFO.

5.1.3 JACK alone with minimumpossible latency

Finally, we considered a scenario with JACKconfigured to have only 64 samples as buffer-sizeand a sample-rate of 96kHz, resulting in 667µsof period. This corresponds to the minimumpossible latency achievable with the mentionedaudio hardware. When working at these small

Figure 4: Server period and clients end timeof JACK with minimum possible latency sched-uled by SHRUB (reservation period was 2001µs,i.e., three times the JACK period).

SHRUB FIFO CFS

Min. 650.0 629.0 621.0Max. 683.0 711.0 1369.0Average 666.645 666.263 666.652Std. Dev 0.626 1.747 2.696Drv. End Min. 6.0 6.0 5.0Drv. End Max. 552.0 602.0 663.0

Table 3: period and driver end time in the3 cases (values are in µs).

values, even if there are no other applications inthe system and the overall load if relatively low,xruns might occur anyway due to system over-heads, resolution of the OS timers, unforeseenkernel latencies due to non-preemptive sectionsof kernel segments, etc.

In Figures 2, 3 and 4, we plot the clientend times, i.e., the completion instants ofeach client for each cycle (relative to cycle starttime). Such metric provides an overview ofthe times at which audio calculations are fin-ished by each client, as well as the audio periodtiming used as a reference. Things are work-ing correctly if the last client end time is lowerthan the server period (667µs in this case).Clients are connected in a sequential pipeline,with Client0 being connected to the input(whose end-times are reported in the bottom-most curve), and Client9 providing the finaloutput to the JACK output driver (whose end-times are reported in the topmost curve). Alsonotice that when a client takes longer to com-plete, the one next to it in the pipeline startslater, and this is reflected on the period durationtoo. Some more details about this experimentsare also reported in Table 3.

6 Conclusions and future work

In this work the JACK sound subsystem hasbeen modified so as to leverage adaptive re-source reservations as provided by the AQuoSAframework. It appears quite clear that bothbest effort and POSIX compliant fixed prior-ity schedulers have issues in supporting multiplereal-time applications with different timing re-quirements, unless the user takes the burden ofsetting correctly the priorities, which might behard when the number of applications needingreal-time support is large enough. On the otherhand, resource reservation based approaches al-low each application to be configured in isola-tion, without any need for a full knowledge ofthe entire set of deployed real-time tasks on thesystem, and the performance of each applica-tion will depend exclusively on its own work-load, independently of what else is deployed onthe system. We therefore think that it can bestated that resource reservations, together withadaptive feedback-based control of the resourceallocation and effective bandwidth reclamationtechniques, allows for achieving precise schedul-ing guarantees to individual real-time applica-tions that are concurrently running on the sys-tem, though there seems to be some space forimproving the currently implemented budgetfeedback-control loop.

Along the direction of future research aroundthe topics investigated in this paper, we planto explore on the use of two recently pro-posed reservation based schedulers, the IR-MOS [Checconi et al., 2009] hybrid EDF/FPreal-time scheduler for multi-processor systemson multi-core (or multi-processor) platforms,and the SCHED DEADLINE [Faggioli et al.,2009] patchset, which adds a new schedulingclass that uses EDF to schedule tasks.

References

Luca Abeni and Giorgio Buttazzo. 1998. Inte-grating multimedia applications in hard real-time systems. In Proceedings of the IEEEReal-Time Systems Symposium, Madrid,Spain, December.

Luca Abeni, Tommaso Cucinotta, GiuseppeLipari, Luca Marzario, and Luigi Palopoli.2005. QoS management through adaptivereservations. Real-Time Systems Journal,29(2-3):131–155, March.

Dr. James H. Anderson and Students. 2006.Linux Testbed for Multiprocessor Schedul-

ing in Real-Time Systems (LITMUSRT ).http://www.cs.unc.edu/~anderson/litmus-rt/.

Fabio Checconi, Tommaso Cucinotta, DarioFaggioli, and Giuseppe Lipari. 2009. Hier-archical multiprocessor CPU reservations forthe linux kernel. In Proceedings of the 5th In-ternational Workshop on Operating SystemsPlatforms for Embedded Real-Time Applica-tions (OSPERT 2009), Dublin, Ireland, June.

Dario Faggioli, Fabio Checconi, Michael Tri-marchi, and Claudio Scordino. 2009. An edfscheduling class for the linux kernel. In Pro-ceedings of the 11th Real-Time Linux Work-shop (RTLWS 2009), Dresden, Germany, Oc-tober.

S. Kato, R. Rajkumar, and Y. Ishikawa. 2010.Airs: Supporting interactive real-time appli-cations on multicore platforms. In Proc. ofthe 22nd Euromicro Conference on Real-TimeSystems (ECRTS 2010), Brussels, Belgium,July.

Klara Nahrstedt, Hao-hua Chu, and SrinivasNarayan. 1998. QoS-aware resource manage-ment for distributed multimedia applications.J. High Speed Netw., 7(3-4):229–257.

Luigi Palopoli, Luca Abeni, Tommaso Cu-cinotta, Giuseppe Lipari, and Sanjoy K.Baruah. 2008. Weighted feedback reclaim-ing for multimedia applications. In Proceed-ings of the 6th IEEE Workshop on EmbeddedSystems for Real-Time Multimedia (ESTIMe-dia 2008), pages 121–126, Atlanta, Georgia,United States, October.

Luigi Palopoli, Tommaso Cucinotta, LucaMarzario, and Giuseppe Lipari. 2009. AQu-oSA — adaptive quality of service architec-ture. Software – Practice and Experience,39(1):1–31.

Vanessa Romero Segovia, Karl-Erik Arzen,Stefan Schorr, Raphael Guerra, GerhardFohler, Johan Eker, and Harald Gustafsson.2010. Adaptive resource management frame-work for mobile terminals - the ACTORS ap-proach. In Proc. of the Workshop on AdaptiveResource Management (WARM 2010), Sto-cholm, Sweden, April.

0

500

1000

1500

2000

2500

3000

0 10000 20000 0 10000 20000 0 10000 20000 0 10000 20000 0 10000 20000

(1) CFS/CFS (2) FIFO/FIFO (3) FIFO/FIFO (4) AQuoSA/AQuoSA (5) SHRUB/SHRUB

(a)

0

0.2

0.4

0.6

0.8

1

0 750 1500 2250 3000 0 1500 3000 4500 6000 0 750 1500 2250 3000 0 750 1500 2250 3000 0 750 1500 2250 3000

(b)

0

200

400

600

800

1000

1200

1400

0 10000 20000 30000 40000 0 10000 20000 30000 40000 0 10000 20000 30000 40000 0 10000 20000 30000 40000 0 10000 20000 30000 40000

CPU TimePredicted Q

Set Q

(c)

0

2000

4000

6000

8000

10000

12000

14000

0 1500 3000 4500 6000 0 1500 3000 4500 6000 0 1500 3000 4500 6000 0 1500 3000 4500 6000 0 1500 3000 4500 6000

(d)

0

0.2

0.4

0.6

0.8

1

0 10000 20000 0 10000 20000 0 10000 20000 0 10000 20000 0 10000 20000

(e)

Figure 5: From top to bottom: driver end time and its CDF, JACK CPU Time and budgets,response time of rt-app and its CDF of the experiments with JACK and a VoIP alike load. Asin Figure 1, time is in µs on the Y axes of (a)-(c)-(d), while the X axes accommodate applicationcycles.