Tuesday, June 19, 2018

flac vs. sox - the showdown

Today I had the idea to benchmark my steroid pumped up flac and sox binaries for decoding  a flac.

Why is that?

Both apps offer the very same functionality. And are widely used for that job.




On e.g. a Logitechmediserver sox could also be used instead of flac to decode flacs. 

That's actually what I do, because I currently resample the data to 384k at the same time.
Basically instead of feeding sox through flac (default setting)  I let sox do the whole job.

How did I run the test?
After finishing my earlier steroid benchmarks I installed the self-compiled high performance versions of flac and sox on my Ubuntu system.

I use these for the test now. Both are dynamically linked.

For the test I've taken a 16bit C0 test flac.

And that's what I've done:

*********************************************************************************************

echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

Case1:


perf stat -r 10 -B sox -qq --no-dither ./test16-C0.flac -t wavpcm ./test16.wav

Case2:


perf stat -r 10 -B flac --totally-silent -d -f -o ./test16.wav ./test16-C0.flac  

*********************************************************************************************

And here comes the result:

Case1:

 Performance counter stats for 'sox -qq --no-dither ./test16-C0.flac -t wavpcm ./test16.wav' (10 runs):

        609,739540      task-clock (msec)         #    0,999 CPUs utilized            ( +-  0,68% )
                 6      context-switches          #    0,010 K/sec                    ( +- 23,25% )
                 0      cpu-migrations            #    0,000 K/sec                    ( +-100,00% )
               352      page-faults               #    0,578 K/sec                    ( +-  0,33% )
     1.633.659.459      cycles                    #    2,679 GHz                      ( +-  0,69% )
     3.966.964.408      instructions              #    2,43  insn per cycle           ( +-  0,00% )
       507.480.648      branches                  #  832,291 M/sec                    ( +-  0,00% )
         5.598.974      branch-misses             #    1,10% of all branches          ( +-  0,08% )

       0,610219378 seconds time elapsed                                          ( +-  0,68% )

Case2:

Performance counter stats for 'flac --totally-silent -d -f -o ./test16.wav ./test16-C0.flac' (10 runs):

        507,810385      task-clock (msec)         #    0,999 CPUs utilized            ( +-  0,23% )
                 5      context-switches          #    0,009 K/sec                    ( +- 24,98% )
                 0      cpu-migrations            #    0,000 K/sec                  
               109      page-faults               #    0,215 K/sec                    ( +-  0,81% )
     1.358.493.244      cycles                    #    2,675 GHz                      ( +-  0,19% )
     2.917.924.459      instructions              #    2,15  insn per cycle           ( +-  0,00% )
       220.421.986      branches                  #  434,064 M/sec                    ( +-  0,01% )
         5.643.611      branch-misses             #    2,56% of all branches          ( +-  0,07% )

       0,508171327 seconds time elapsed                                          ( +-  0,23% )


********************************************************************************

Interesting result again. flac is around 17% faster than sox for the very same job. 

What's even more interesting is that if you look at the number of executed instructions you'll notice that sox seems to run a million (25%) more instructions for the job. 
Hmmh. That would somehow explain the difference. But what the heck is sox doing there!?!? 


Bottom line

By looking at above I'd say, if you just need the decoding part for a flac and no DSP (resampling/dithering/format conversion etc.) you better use flac only. 
If you need flac decoding AND DSP jobs to be done, better use sox only. 

Perhaps I try to get in touch with the sox designer to see what's going on with sox.

Enjoy.






No comments:

Post a Comment