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/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
