[LAU] multiJACK patch management: the first glimmerings of success
nettings at stackingdwarves.net
Wed Apr 6 07:27:44 UTC 2016
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...
Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487
Meister für Veranstaltungstechnik (Bühne/Studio)
More information about the Linux-audio-user