OK. Further to my last post... I killed the cron job that ran 3 minutes past the top of the hour. Now I get lots of lines of "internal buffer inconsistency" on the console after running for a few hours before Liquidsoap eventually segfaults. It doesn't show up in the log at all.
On 3/13/2016 9:08 PM, Patrick Perdue wrote: > Hello: > > I have been running a simple live stream using a Raspberry Pi2 and > Liquidsoap, streaming to a local Icecast server and archiving to wav, > using a Lexicon Alpha (class compliant USB audio device) problem free, > until I recently switched to a Behringer UMC204. In order to make the > UMC204 work on the Pi, I added dwc_otg.fiq_fsm_enable=0 to cmdline.txt. > This is apparently a known fix for many CS-based audio interfaces, such > as the Behringer UMC line, Focusrite Scarlets, Presonus Audiobox, etc. > I also had to export AUDIODRIVER=alsa and AUDIODEV=hw:1,0 to my > environment, which I didn't have to do with the Alpha, at least for use > with Liquidsoap. In Liquidsoap itself, I am addressing the device as > plughw:1,0. > > Everything works, but after roughly 24 hours of running, Liquidsoap > segfaults on something that looks like it is related to alsa. Here are > some lines from the log before it crashes. > > 2016/03/13 20:00:00 > [/mnt/archive/stream/%Y/%m/%Y-%m-%d-%H-%M-%S(dot)wav:3] Re-opening > output pipe... > 2016/03/13 20:02:13 [input.alsa_4881:2] Overrun! > 2016/03/13 20:02:13 [input.alsa_4881:2] Trying to recover.. > 2016/03/13 20:05:36 [input.alsa_4881:2] Overrun! > 2016/03/13 20:05:36 [input.alsa_4881:2] Trying to recover.. > 2016/03/13 20:06:14 [input.alsa_4881:2] Overrun! > 2016/03/13 20:06:14 [input.alsa_4881:2] Trying to recover.. > 2016/03/13 20:06:14 [out_ic_mp3:2] Error while sending data: could not > write data to host: Broken pipe in write()! > > I have a CPU intensive task that runs at 3 minutes past the top of the > hour, and most of these alsa overruns seem to happen between 5 and 6 > minutes after, while the task is still running. > So, aside from not running this job (which would probably help,) can I > increase alsa.buffer_length to something reasonable to perhaps make this > less of an issue? > I'm really not very familiar with alsa in general, so don't know what > constitutes "reasonable" in this case. ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140 _______________________________________________ Savonet-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/savonet-users
