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_re...@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 <rom...@liquidsoap.fm <mailto:
> rom...@liquidsoap.fm>> wrote:
> >
> > Hi Matt,
> >
> > 2013/10/2 Matt Camp <m...@noise.net.nz <mailto:m...@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/raspberrypito
> > 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
>
------------------------------------------------------------------------------
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
