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

[Jörn Nettingsmeier]

On 04/05/2016 11:21 PM, Robin Gareus wrote:

>> When exporting, I have seen something that might be similar to what
>> Jonathan might be seeing: a freewheeling, 100% CPU-bound process only
>> seems to use a fraction of the available CPU even on a single core. Now
>> this might indicate a real problem, or it might indicate that the CPU
>> load tools I'm using do not accurately report what's going on under
>> tight real-time conditions with loads of context switches.
>
> Ardour export? if so that does not use jack's parallel graph at all.
> Ardour is a single jack client.

not if you have inserts...

> 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...


-- 
Jörn Nettingsmeier
Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487

Meister für Veranstaltungstechnik (Bühne/Studio)
Tonmeister VDT

http://stackingdwarves.net