Ok, I've done a few tests with ogg/vorbis.

On the raspberry pi (non-overclocked) the use of ogg/vorbis basically pushes the CPU to 97-100% and the audio is totally unusable. I tried both cbr (128k) and abr(64-192k) and there was no noticable difference.

When overclocked to 900MHz cpu use was still in the high 90% range, which causes massive audio corruption.

All tests were performed using a Behringer UCA202 USB audio interface, and input.alsa(). 

I am still unable to get jack to work with the raspberry pi... all attempts with this audio interface result in heavy static and white noise over the audio along with plenty of overrun errors. I have another usb audio interface on order which I will test soon but I'm not holding out much hope for any great improvement.

For comparison I've been also testing with an OLinuXino A20 board, and vorbis there still sits at around 85-93% cpu, however due to the dual-core board this actually sounds mostly ok... there are still the occasional glitches however so I wouldn't want to use this in production.

Fdkaac however sits at only 18% cpu use on the A20 board and the audio is rock solid, even during CPU intensive activities like apt-get updates, which is great news. At the moment my continued efforts to build an embedded liquidsoap live encoder will be focussed around this, or similar boards as they are just so much more capable than the raspberry pi.



On 4 October 2013 12:15, Peter Retep <peter_retep@gmx.de> wrote:
Hi Matt,

Congratulations to your work!
Could you please additionally benchmark with ogg/vorbis?
I would be interested in the results.

BR, Peter

Am 03.10.2013 13:28, schrieb Matt Camp:
> Awesome, that definitely seems to have done the trick... I now have stable-sounding live streaming from a Raspberry Pi!
>
> One still has to be careful with other processes on the device however as it's living on the edge... as evidenced below when I fired up apt-get in another terminal and pushed the CPU up near 100% use briefly.... I am still seeing the occasional dropout even when I leave it alone, so I suspect there are probably still a few other processes around that could be pruned back to streamline things more.
>
> Thanks for your help!
>
> -----
>
> 2013/10/03 11:18:47 [threads:3] Created thread "wallclock_icecast" (1 total).
> 2013/10/03 11:18:47 [threads:3] Created thread "input.alsa_4842" (2 total).
> 2013/10/03 11:18:47 [threads:3] Created thread "wallclock_alsa" (3 total).
> 2013/10/03 11:18:47 [clock.wallclock_icecast:3] Streaming loop starts, synchronized with wallclock.
> 2013/10/03 11:18:47 [input.alsa_4842:3] Using ALSA 1.0.25.
> 2013/10/03 11:18:47 [clock.wallclock_alsa:3] Streaming loop starts, synchronized by active sources.
> 2013/10/03 11:18:47 [mksafe:3] Switch to safe_blank.
> 2013/10/03 11:18:48 [mksafe:3] Switch to warp_prod_4848 with transition.
> 2013/10/03 11:18:51 [input.alsa_4842:2] Overrun!
> 2013/10/03 11:18:51 [input.alsa_4842:2] Trying to recover..
> 2013/10/03 11:20:14 [input.alsa_4842:2] Overrun!
> 2013/10/03 11:20:14 [input.alsa_4842:2] Trying to recover..
> 2013/10/03 11:20:21 [input.alsa_4842:2] Overrun!
> 2013/10/03 11:20:21 [input.alsa_4842:2] Trying to recover..
> 2013/10/03 11:20:21 [warp_prod_4848:3] Buffer emptied, start buffering...
> 2013/10/03 11:20:21 [mksafe:3] Switch to safe_blank with transition.
> 2013/10/03 11:20:22 [mksafe:3] Switch to warp_prod_4848 with transition.
> 2013/10/03 11:20:28 [input.alsa_4842:2] Overrun!
> 2013/10/03 11:20:28 [input.alsa_4842:2] Trying to recover..
> 2013/10/03 11:20:33 [input.alsa_4842:2] Overrun!
> 2013/10/03 11:20:33 [input.alsa_4842:2] Trying to recover..
> 2013/10/03 11:20:53 [input.alsa_4842:2] Overrun!
> 2013/10/03 11:20:53 [input.alsa_4842:2] Trying to recover..
> 2013/10/03 11:20:53 [warp_prod_4848:3] Buffer emptied, start buffering...
> 2013/10/03 11:20:53 [mksafe:3] Switch to safe_blank with transition.
> 2013/10/03 11:20:54 [mksafe:3] Switch to warp_prod_4848 with transition.
> 2013/10/03 11:20:59 [input.alsa_4842:2] Overrun!
> 2013/10/03 11:20:59 [input.alsa_4842:2] Trying to recover..
> 2013/10/03 11:21:04 [input.alsa_4842:2] Overrun!
> 2013/10/03 11:21:04 [input.alsa_4842:2] Trying to recover..
>
>
> On 3 October 2013 03:05, Romain Beauxis <romain@liquidsoap.fm <mailto:romain@liquidsoap.fm>> wrote:
>
>     Hi Matt,
>
>     2013/10/2 Matt Camp <matt@noise.net.nz <mailto:matt@noise.net.nz>>
>     >
>     > So after quite a few headaches with various libraries and plenty of time spent recompiling, I've done a few tests using the Raspberry Pi (raspbian armhf) as a potential live stream source.
>
>     Cool, sorry it had to be so painful..
>
>
>     > I'm only interested in AAC+ 64kbit stereo, so my tests are focussed there.
>     >
>     > I'm using a Behringer UCA202 class-compliant USB audio interface as the audio source, with input.alsa() and streaming to an icecast2 server.
>     >
>     > I've tested with both the %aacplus and the %fdkaac encoders.
>     >
>     > %aacplus results in approximately 54-57% CPU usage, with minor audio glitches occuring every 10 seconds so.. these glitches are definitely more frequent (and more audible) when the CPU usage is higher. (see below).
>     >
>     > %fdk-aac using mpeg4_he_aac results in approx 51-55% CPU usage, so is a slight improvement.
>     >
>     > %fdk-aac using mpeg4_he_aac_v2 results in a fairly solid 42% CPU usage... a definite improvement there, although the audio glitches are still there occasionally... enough that I wouldn't want to use this for anything production just yet.
>     >
>     > Interestingly the CPU usage when streaming an mp3 file using this encoder is 55-60%. Even when doing other tasks to push the CPU higher, the audio is still a lot cleaner and more glitch-free than any of the live stream tests. (although they do appear when CPU goes over around 75-80%)
>     >
>     > My suspicion is that these audio glitches are related to the ALSA driver not quite talking with my USB audio interface correctly, although I'm not seeing any 'catch up' errors in the liquidsoap logs...
>     >
>     > I've used the guide at http://wiki.linuxaudio.org/wiki/raspberrypi to tweak the rpi as much as possible for audio, but there are still issues.
>     >
>     > Trying to use Jack on the rpi has been a fairly dismal failure. Jackd1 (patched for the rpi) runs, but even using jack_rec to record a short audio sample results in around one second of clean audio, then overlaid with static / white noise. Trying to run without the -s flag on jackd results in many alsa xrun error warnings, so I think the rpi is just failing to keep up with the audio.
>     >
>     > Liquidsoap also segfaults as soon I try to use input.jack, so something is quite broken there.
>     >
>     > Attempting to use jackd2 ended with failure to allocate memory and Bus Error's when trying to launch jack.
>     >
>     > I've not tried portaudio or pulseaudio yet, but I'm not really sure if either would be any better than ALSA.
>     >
>     > I'm planning to try to find a different USB audio interface to try out so testing will continue.
>
>     You are most likely right on your intuition of the problem. If you use input.alsa, the clock of the whole script will be assigned to that device's clock. Should the clock conflict with the CPU's clock or network lags, etc.. you may very likely experience this kind of issue.
>
>     There is a potential solution in liquidsoap, which is to use different clocks for the audio input and the icecast output. The documentation is here: http://savonet.sourceforge.net/doc-svn/clocks.html
>     In particular, you may be interested by the "External clocks: decoupling latencies" section.
>
>     Hope this helps,
>     Romain
>
>
>     ------------------------------------------------------------------------------
>     October Webinars: Code for Performance
>     Free Intel webinars can help you accelerate application performance.
>     Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
>     the latest Intel processors and coprocessors. See abstracts and register >
>     http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
>     _______________________________________________
>     Savonet-users mailing list
>     Savonet-users@lists.sourceforge.net <mailto:Savonet-users@lists.sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/savonet-users
>
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Savonet-users mailing list
> Savonet-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/savonet-users


------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
_______________________________________________
Savonet-users mailing list
Savonet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/savonet-users