audio/deadbeef: Default to using libmpg123 instead of libmad

[diizzy]

Summary

libmpg123 is much faster than libmad and is also in active development compared to libmad which hasn't seen any upstream development in years.

[danfe]

According to the upstream author, initially libmad was the only supported decoder, most likely because mpg123 did not offer a library, being just a console player. At some point, several bugs were found in libmad that caused incorrect decoding of some MP3 files, so libmpg123 support was added (as it become available by that time). However, it is recommended to enable both backends during the package build, because users can switch backends during run time without recompilation. Official binaries for GNU/Linux and macOS include both. This is the quote from the configure script:

NOTE: the mp3 plugin has multiple backends since deadbeef 0.7, both libmad and libmpg123 are supported at the same time, and can be selected by the user from plugin configuration dialog. At least one of them is required to satify mp3 plugin dependencies. But having both is preferred.

The author recalls there was no noticeable performance difference between the two on x86 platforms (albeit that assertion is pretty dated). That said, I'm more inclined to enable both options by default thus far, but I'll keep thinking about it while watching the actual situation with libmad.

[diizzy]

Hi,

Thanks for looking into this, while x86 is powerful enough to make the difference negligible in the end there's still quite a difference in performance and it's even greater on platforms with lower overall performance such as ARM. I'm not sure why it's preferred to have redundant libraries but as far as I can tell format support seems to be added on top of each library such as ffmpeg which can potentially replace the majority of other decoders supported although the current code does not support full utilization of ffmpeg. In general I think dependencies should be kept at a minimum without sacrificing convenience (functionality/usability) but I have no strong opinion if you want to include both decoders or just keep it as is.

fwiw, here's a quick benchmark I did on two boxes I have available.

=== Intel G3220 (amd64) (FreeBSD 12.1) ===

/usr/bin/time -h madplay --output=null:/dev/null ./sample.mp3
146107 frames decoded (1:03:36.6), +0.5 dB peak amplitude, 0 clipped samples
        11.78s real             11.11s user             0.15s sys

/usr/bin/time -h mpg123 -o dummy ./sample.mp3
[63:37] Decoding of sample.mp3 finished.
        6.55s real              6.18s user              0.34s sys

=== Allwinner H5 (arm64) @ ~820Mhz (FreeBSD -CURRENT r354689 without debugging) ===

/usr/bin/time -h madplay --output=null:/dev/null ./sample.mp3
146107 frames decoded (1:03:36.6), +0.5 dB peak amplitude, 0 clipped samples
        1m20.94s real           1m20.60s user           0.33s sys

/usr/bin/time -h mpg123 -o dummy ./sample.mp3
[63:37] Decoding of sample.mp3 finished.
        34.75s real             31.35s user             3.40s sys

[danfe]

@daniel.engberg.lists_pyret.net wrote:

I'm not sure why it's preferred to have redundant libraries but as far as I can tell format support seems to be added on top of each library such as ffmpeg which can potentially replace the majority of other decoders supported although the current code does not support full utilization of ffmpeg.

I also do not know all the reasons why FFmpeg is not utilized more broadly, but there must be some valid ones (I trust the author). For example, APE decoder plugin, ffap, was factored out from FFmpeg's apedec mainly because of the following:

demuxer and decoder joined into 1 module
no mallocs/reallocs during decoding
streaming through fixed ringbuffer (small mem footprint)
24bit support merged from rockbox

Sometimes I think that it would be nice to have alternative implementation (e.g. based on audio/mac port).

In general I think dependencies should be kept at a minimum without sacrificing convenience (functionality/usability) but I have no strong opinion if you want to include both decoders or just keep it as is.

Being able to switch decoders, if necessary, allows for better flexibility and control (by the user); according to the author, he does that in the official upstream builds and appreciates when downstream packagers follow.