On Wed, Oct 31, 2012 at 03:37:15PM +0000, Daniel James wrote: > Hi Ken, > > > Since liquidsoap also encodes, that will make a significant different > > with using mplayer.. > > One way to test that is to disable any MP3 or Ogg streams from Airtime > and just run the ALSA output for a while. You should see the load > average in 'top' drop significantly.
There was no encoding going on. At all. The only output in Airtime was ALSA (or AO). When I was running my hacky little script, that only hit ALSA as well, no output stream. > > Also, your Apache CPU load sounds high. Does that percentage drop when > all the users log out of the Airtime admin interface? > > I am all in favour of hardware recycling, but when running 24/7 an old > P4 is probably not energy efficient in terms of watts/performance. I run > Airtime on a recycled Opteron 170 dual-core which is more than adequate > for a small station, if a little more power hungry than a P4, and also a > HP Microserver which has similar performance to the Opteron but is very > energy efficient at around 35W total. > > >>> Finally, how well does liquidsoap run under RT priority? I've > >>> used Ingo kernels for 6 years now, perhaps it might be worthwhile > >>> to try installing one on this box and giving liquidsoap rt prio > > > I have no idea how liquidsoap works with RT. Would be nice to try > > and report here! > > It should not be necessary if the Airtime server is adequately specified > and running normally. Deterministic latency in the kernel would only be > a sticking plaster if the real problem is that the server is > underpowered for the task. > Well ultimately that's the problem then. Although I do have to wonder why it takes 3-10 hours before any glitch appears. That smells to me like a memory leak. Or, maybe that timing is just coincidence, and the actual problem is caused by people hitting the web interface and thus making Apache starve liquidsoap for CPU. It'd be interesting to find out. But, alas, the technical on-site contact is now gone, and won't be back until next year, so unfortunately any fixes that require touching the hardware will have to wait until then. What's likely to happen next year is that the "underpowered" server will stay in place as a stream receiver-- or get replaced with something even lighter weight like a Linksys USB router, NSLUG, Beagleboard/Raspbery, etc--, and a more powerful multi-core CPU will be placed somewhere else on the internet, to run Airtime and do the transcoding and user interface, feeding the station remotely. The new Airtime 2.2 appears to use mp3replaygain, which dominates the P4's CPU at 70%, so the other alternate solution-- moving Apache and database to another machine and just communicating with the playout engine on the P4 using RabbitMQ and JSON-- will probably not be viable. But it's very nice that Airtime has that much modularity. So, for now, the current "solution" they've found, is to restart the airtime-playout engine every hour with a cron job. Ugly, but that seems to prevent the skipping/glitch problem. They seem happy with that as a stopgap until they find some newer, better hardware. Thanks again for all the help! -ken ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ Savonet-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/savonet-users
