Excellent stuff, thanks for such a detailed effort!
Has anyone tried using a usb audio interface for live streaming yet on an
rpi?
On 20 July 2012 12:44, Anthony Williams <[email protected]> wrote:
> **
> 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]>
> <[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
>
>
------------------------------------------------------------------------------
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
