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 _______________________________________________ Linux-audio-user mailing list Linux-audio-user@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-userReceived on Wed Apr 6 12:15:01 2016
This archive was generated by hypermail 2.1.8 : Wed Apr 06 2016 - 12:15:01 EEST