Hello
I spent yesterday compiling and testing liquidsoap on the new Raspbian
distribution. The performance improvement is very good. Prepare for a
marathon message... sorry!
---Installing fun---
However, installing it was a problem. After dependencies were met and
liquidsoap 1.0.1 compiled and installed, liquidsoap would not run,
failing with 'Illegal instruction'. Investigations with gdb gave this:
Starting program: /usr/bin/liquidsoap
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/lib/arm-linux-gnueabihf/libthread_db.so.1".
Program received signal SIGILL, Illegal instruction.
0x40b8e080 in ?? () from /usr/lib/arm-linux-gnueabihf/libmp3lame.so.0
Tracepoint 1 at 0x40b8e080
#0 0x40b8e080 in ?? () from /usr/lib/arm-linux-gnueabihf/libmp3lame.so.0
#1 0x40b8d67a in _init () from /usr/lib/arm-linux-gnueabihf/libmp3lame.so.0
#2 0x4000f358 in ?? () from /lib/ld-linux-armhf.so.3
#3 0xbefff900 in ?? ()
Cannot access memory at address 0x0
#4 0xbefff900 in ?? ()
Cannot access memory at address 0x0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
It appeared that libmp3lame was failing somehow, but I don't have the
expertise to investigate further, so I uninstalled the package and
compiled libmp3lame from source instead.
Then a similar error, this time with libaacplus
Starting program: /usr/bin/liquidsoap
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/lib/arm-linux-gnueabihf/libthread_db.so.1".
Program received signal SIGILL, Illegal instruction.
0x40b5fdb8 in ?? () from /usr/lib/arm-linux-gnueabihf/libaacplus.so.2
#0 0x40b5fdb8 in ?? () from /usr/lib/arm-linux-gnueabihf/libaacplus.so.2
#1 0x40b5fc4a in ?? () from /usr/lib/arm-linux-gnueabihf/libaacplus.so.2
#2 0x40b5fc4a in ?? () from /usr/lib/arm-linux-gnueabihf/libaacplus.so.2
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Once again, compiling libaacplus from source solved this problem, and
liquidsoap could run!
---Performance---
Performance is much improved compared to running on the old
distribution. Since Romain found all the decoders worked well on the old
distribution, I'll assume the same and will focus on encoder performance.
The initial Debian Squeeze distribution for Raspberry Pi used the
architecture 'armel', whereas the new one uses 'armhf', which has
increased floating-point hardware support at the expense of
compatibility with older ARM architectures.
http://wiki.debian.org/ArmHardFloatPort
<http://wiki.debian.org/ArmHardFloatPort> gives a better explanation
than I can.
All of these tests were done on a home broadband connection streaming to
a remote icecast server. I checked to make sure bandwidth was not a
limiting factor. I tested with input as sine(), and then with a 256kbps
mp3 file. Used liquidsoap-1.0.1 tarball, dependencies from Raspbian
repositories (apart from the above mentioned libmp3lame and libaacplus)
CPU usage measured is for the liquidsoap process, not the system as a whole.
mp3: Using sine() with (bitrate=192, samplerate=44100, stereo=true)
worked, with CPU usage of 60%. It could not manage streaming the mp3
file at 192kbps, but reducing the output quality to 64k worked (cpu 90%)
96k worked, but the processor was almost maxed, and doing anything else
(running 'top') caused 'catchup' problems.
wav: I was limited by my upload bandwidth, but have previously not seen
an issue with CPU usage. Streaming the mp3 to a file gave CPU usage of
35%, so all's well.
ogg/vorbis: (samplerate=44100, channels=2, range of qualities). Sine()
worked fine at 70% CPU usage, streaming an mp3 worked well, with CPU in
the range of 80-87%. Quality setting did not affect CPU usage too
dramatically, only a few % either way.
ogg/theora: I attempted some basic video streaming using
video.volume(input) and vorbis audio, very low video bitrates. This
wasn't going to work, immediate 'we must catchup', although it did
generate a couple of frames.
ogg/speex: (samplerate=44100, stereo=true, quality=2) was unusable,
reducing samplerate to 16kHz gave 60% usage with sine(), 90% with the mp3.
ogg/flac: (samplerate=44100, channels=2, compression=3,
bits_per_sample=16) ran well with sine(), using 40% CPU, I could not
test it with the mp3 as my broadband connection is too slow, but there
appears to be plenty of CPU headroom to allow that. Outputting the mp3
input to a file gave 60% cpu usage.
aac: (channels=2, samplerate=44100, bitrate=64, adts=true) worked very
well, with sine() producing 30% cpu usage, mp3 50%. Bitrate could be
adjusted across a wide range with only a few % difference.
aacplus: (channels=2, samplerate=44100, bitrate=64) also worked well,
sine() produced 50% CPU usage, mp3 streaming 75%. I couldn't select
bitrates over 70. Is that a limitation of aacplus format?
So, the tl;dr version: All the (audio) encoders work well to some
extent, although a little more CPU headroom for OS tasks and any
liquidsoap goodies may be wanted, especially with vorbis and mp3
encoding. But for basic tasks such as streaming an input from a USB
sound card, the Raspberry Pi with Raspbian OS seems ideal!
I hope this essay and the possible over-detailed encoder analysis has
been useful.
Many thanks
Anthony
On 20/07/12 01:42, Romain Beauxis wrote:
2012/7/19 Martin Konečný<[email protected]>:
Would the improved Debian port improve the performance of a floating point
encoder on the RPi? Something tells me no.
It certainly does, see:
http://www.memetic.org/raspbian-benchmarking-armel-vs-armhf/
Just ordered mine last week, still really hard to get here in Canada :)
Bon courage!
BTW, the work on the shine encoder continues there:
https://github.com/savonet/shine
Romain
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Savonet-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/savonet-users
