Page 1 of 1

FLAC to Apple Lossless CPU load

Posted: Thu May 11, 2006 7:56 pm
by ye
I converted a FLAC file to Apple Lossless. Max uses only 50% CPU load of one CPU (according to activity monitor). I have 120-140% load idling (in terms of one CPU). So Max here not even uses one CPU completely. Any idea why?

Edit: the used disk ransfer rates (about 4MB/s while converting) are far away from the disk performance, so this is not the limiting factor.

Dual 2GHz G5, 3GB Ram, OS 10.4.6, Max 0.5.6

Posted: Tue May 16, 2006 10:59 pm
by woody77
Are the G5s dual core? If so, this would explain it, as while multiple encoders can execute at a time, if only one track is being encoded, it only uses one thread, which maxes out only one core.

Posted: Wed May 17, 2006 12:56 pm
by krmathis
woody77. The later PowerMac G5's have Dual Core processors.
But I am 99% sure that the Dual 2.0GHz was available as Single Core as well, before they went Dual Core some 7-8 months ago.

If 'ye' have one of the later Dual Core G5's, then it explains why it dont use all the processing power. If not, then there might be other reasons.

Posted: Thu May 25, 2006 5:32 pm
by ye
It is a machine with two single core CPUs.

Activity monitor reports:
%CPU: 66 (200% would be full load)
Threads: 6

overall System load: (here 100% is full load)
%User: 30.5
%System: 23.5
%Nice: 0
%idle: 46

If I run the same conversion twice, the Max CPU load goes slightly up to something like 75%.
Some other applications (Safari, Mail, Acrobat reader,....) were also running.

You see the percentage vary somewhat, also from my first post, but the symptom remains always.

It seems not possible to attach screen shots here, but I can mail these to illustrate, if someone wants to see them.

Posted: Mon May 29, 2006 11:29 am
by ye
I did some more experiments. The bottle neck could be the data transfer to the hard disk. The data transfer rate is O.K but there are a LOT of read/write operations per second (read >200/sec, write >800/sec).

In the second run of the same file I get, as noted above, a higher CPU load, nearly no read operations and about 1000 writes per second. So some cache effect I suppose.

The problem seems to be that there is a lot of read/write of TO SMALL files, hence driving the disk to its limits.

Posted: Mon May 29, 2006 3:02 pm
by sbooth
This is interesting.

For the reads, I am using ExtAudioFileRead. I have no idea how the caching works internally.

For the writes, I am using ExtAudioFileWrite throughout Max. I will try to switch over to ExtAudioFileWriteAsync and see if that improves performance.

Edit: I tried using the async write, and the performance was essentially identical (10 vs. 11 seconds to encode as Apple Lossless). I think the benefits of using async writes would be greater on slower drives, though.

Posted: Mon May 29, 2006 3:34 pm
by ye
I'm using a Raid5 SATA disk array. Only for small transfer blocks I get low transfer rates in bench programs (at least: 7MB/s for 4 kbyte blocks, 15MB/s for 8 kbyte blocks and >36MB/s for 16 kbyte and above).
So the only possibility, I see, is that the data blocks transfered to the disk are 8 kByte or even smaller (perhaps wrong or un-buffered output ????).

Max 0.6 update

Posted: Tue May 30, 2006 3:55 pm
by ye
With Max 0.6 the situation is somewhat different.

In phase I (converter) I now get nearly 100 % CPU and less write transactions (only about 300/s). This is an improvement, here I got only 60% CPU before.

In phase II (encoder) I still get <50% CPU, a transfer rate of 5MB/s at about 1300 reads/sec. This is evaluates, conspicuously enough, to transfer blocks of 4kB size.

P.S. perhaps I should mention I use a 280MB FLAC file (a complete CD) for the test.