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.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
