Re: [Jack-Devel] Profiling xruns

PrevNext  Index
DateSun, 18 Mar 2012 10:40:23 +0100
From Stéphane Letz <[hidden] at grame dot fr>
ToDénes Almási <[hidden] at rudanium dot org>
Cc[hidden] at lists dot jackaudio dot org
In-Reply-ToDénes Almási [Jack-Devel] Profiling xruns
Follow-UpDénes Almási Re: [Jack-Devel] Profiling xruns
Le 18 mars 2012 à 01:42, Dénes Almási a écrit :

> Hi!
> 
> I am developing a jack client that is handling different input devices
> (like joysticks, touch screens, etc.) and capable of using them as
> musical input devices.
> 
> The architecture is relatively simple: A directed acyclic graph can be
> made up of different boxes, each of them performing different tasks, like
> reading input, generating oscilating values, passing data to a jack midi
> or audio port, etc. When the graph is modified, a non-rt thread generates
> a topologic ordering of the nodes into a linked list and a pointer to the head
> is passed in a ringbuffer to the process function which at its beginning examines
> the content of the buffer and can store the new list. In each process
> call, the list is iterated and the process function is called for each box.
> The edges have buffers which are read and written by the boxes and the topologic
> ordering ensures that only those edges are read in a cycle whose data are
> already computed.
> 
> The problem is: Even without having ANY nodes, thus the process function doing
> practically nothing, sometimes the application does xruns. I am sure that the
> source of these xruns is the application as they show up in the messages
> window of qjackctl with the app's name. Also, I am running in soft mode, which
> I assume, means that xruns indicating that the backend is not fast enough, are
> ignored.
> 
> How could I locate the cause of these xruns? Is there a good practice for profiling
> these problems? I think it is hard because using tools like gprof will make the
> app slow and cause xruns which would never occur without the profiling itself.
> 
> I am using mlockall and a big memory pool, a thread pool (though currently no threads
> are created when process is called), process shielding for the sound card soft irq,
> jackd and the app.
> 
> Jack settings: Rt priority 83, Frames/Period: 128, Sample rate: 48000, Periods/Buffer: 2.
> The latency is 5.33 msec and apps like ardour xrun only very rarely, under heavy usage.
> The machine is a samsung notebook with a core i3 cpu, 3Gb ram and unfortunately an onboard
> soundcard.
> 
> Is it better for xrun debugging to use the dummy interface in order to be totally
> independent of the sound card? Also, could it be the problem that I am using
> clutter for gui? I am quite a beginner in developing audio applications...
> 
> Thank you in advance,
> Dennis

It you are using JACK2, then you can possibly try it's "profiling" mode. When compiled with --profile (added at configure time), JACK2 can produce different timing graph that can be the displayed with gnuplot.

Look at the paper here: http://www.grame.fr/Ressources/pub/Timing.pdf

Stéphane 
PrevNext  Index

1332063641.11728_0.ltw:2,a <F7A48A15-4E7B-4A9C-9FAD-FCDFD2D85B76 at grame dot fr>