[LAU] multiJACK patch management: the first glimmerings of success

[Filipe Coelho]

On 06.04.2016 09:27, Jörn Nettingsmeier wrote:
> On 04/05/2016 11:21 PM, Robin Gareus wrote:
>> The most likely the bottleneck here is disk-i/o (reading audio from all
>> tracks, writing the exported audio).
>
> sorry, what I wanted to say is: performance appears to be 
> unsatisfactory for no apparent reason, and looking at any cpu load 
> meter i see all of my cores half idle.
>
> what i would expect of a very simple export job (say, four mono tracks 
> to stereo, minimal processing) is to perform way better than 3-4x 
> realtime. read throughput is less than 1 MB/s at realtime, write 
> throughput .5 MB/s. even with all the random seeking, I would expect 
> at least 10x realtime speed if it's disk-bound, and several times that 
> if it's cpu bound. i'm reading from and writing to a local RAID1.
>
> now i don't expect to get hand-holding here (i should just get my ass 
> up, look into it, provide some decent metrics and report a bug), all 
> i'm saying is that sometimes, jack-related performance seems weird to 
> a casual user like me (and possibly also the OP). for example, with 
> more intensive processing, i would expect any and all freewheeling 
> export to be cpu-bound, but even there, i barely hit 60% on any of the 
> cores...

I can give a very simple example that would trigger this: a plugin that 
sleeps 1/2 the time of the current buffer size.
(say, if the buffer size is 128 and sample rate 48000, the plugin sleeps 
for 2.66/2 milisecs)
In this case the jack dsp load would be > 50%, but the cpu load would be 
minimal - after all, the plugin is just sleeping.

If you have jack clients or plugins that heavily rely on mutexes, 
semaphores, conditions, etc the same thing might happen.
Most of its processing time will be spent waiting for something else.

If you add a *lot* of printfs in your processing code the same happens too.
printf is not a cpu-intensive function, the issue here is that it 
*locks* waiting for something else.


I think this link should be posted more often: 
http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-for-nothing
If you haven't read it, I recommend you to do so, as soon as possible.