Hi Maxwell, I'm sorry to hear about your unusually bad experience. Let's try to get it straightened out.
On Tue, Mar 2, 2010 at 10:56 PM, Maxwell Rathbone <[email protected]> wrote: > Took me about > half a day to finally get LiquidSoap to compile properly *without* the > following packages: > ocaml-ogg > ocaml-vorbis > ocaml-speex > ocaml-theora > ocaml-faac > ocaml-faad I know liquidsoap has a lot of dependencies, and I hope that you didn't spend too much of your time on the dependencies that you didn't actually need. The packages listed above may not be useful to you. In any case, if you have remarks on how to make the build system simpler, we'd be happy to hear them. My view is that our build system is standard and can't be enhanced much more, the solution to its complexity is to use a package manager, but unfortunately we don't have a package maintainer for redhat-based distributions. > If I check any of the files in this list using the Linux command 'file' > here is the result I see: > /home/liquidsoap/Brad Smith - Pump It Up.mp3: Audio file with ID3 > version 22.0 tag, MP3 encoding It's a good idea to check that. An even better thing is to check using liquidsoap itself: "liquidsoap -r <yourfile.mp3>" will use the normal decoding checks of liquidsoap and thus give a real indication on how that file would play in liquidsoap. > It is important to know that I currently use sc_trans_posix from > shoutcast.com to stream at 128kbps to the same IP above, however to a > different port. The sc_trans_posix application isa ble to stream > consistently and flawlessly. A difference is that liquidsoap always decodes and re-encodes files. This is the cost of entry to its extended possibilities. But the CPU consumption shouldn't make a difference on your machine. The other factor is bandwidth, and if another tool can stream perfectly, liquidsoap should also be able to do it. Still, another way to check that network isn't the issue is to stream to a file: liquidsoap 'output.shoutcast.mp3(...,output.file.mp3(bitrate=128,"/tmp/test.mp3",mksafe(...)))'. > Now when I execute my startup script for liquidsoap, here is a s nippet > of the output I see in the console: > liquids...@albion [~]# ./start.sh > 2010/03/02 23:24:23 >>> LOG START > [...] > 2010/03/02 23:24:23 [root:3] Broadcast starts up! > 2010/03/02 23:24:23 [mksafe:3] Switch to safe_blank. > 2010/03/02 23:24:23 [playlist(dot)pls:3] Prepared "/home/liquidsoap/Bee > Gees - Stayin Alive (Ultimix Remix).mp3" (RID 1). > 2010/03/02 23:24:23 [mksafe:3] Switch to playlist(dot)pls with transition. > > Now when I tune in to the SHOUTcast stream with Winamp, I hear it > 'hiccup' about once every 10-15 seconds. It sounds like a blip for a > fraction of a second, and the audio pauses for that brief fraction of a > second and then continues. It does not appear to matter if I specify a > bitrate to stream at in the startup script or not. The end result is the > same. The hiccup you hear could be a result of switching from the playlist to blank (that's what mksafe does when the playlist is unavailable) but this would only happen between tracks and you'd see more of those "Switch to safe_blank" in the logs so I believe it's not the problem here. > I've read on the mailing list that I should set my log level to 5 to > collect further information. This requires me to change the format of my > startup script to something like this: > liquidsoap 'set("log.level",5);set("root.sync", > false);output.shoutcast.mp3(bitrate=128,host="65.110.47.202", port = > 8008, password = "password", mksafe(playlist("playlist.pls")))' Setting root.sync to false is by no means necessary to get more detailed logs. It will result in sending data too quickly to the shoutcast server, which is unwanted. > When I do this, I'm receiving segmentation faults. If I run the script > several times in a row, maybe one out of 6 or 7 tries it will 'stick' > and start streaming instead of crashing. I did find that if I remove the > set("root.sync", false) part, it is much more stable and does not > segmentation faul, however I'm still stuck with the skipping/hiccup problem. This is interesting. I've had segfaults recently when doing crazy experiments, so I wasn't too worried. In your case this is kind of bad. If root.sync creates the difference I'd be worried about our library sending data to shoutcast (ocaml-cry) but it is pure OCaml code which should never segfault. Which version of ocaml-cry are you using? > Here is the console output I see without the root.sync false option: > [...] Unfortunately, nothing informative in that log. I guess the conclusion of my long reply is to output in a file to find out if the problem is input or output related. If a file works fine then it might be a problem with sending to shout (ocaml-cry is relatively recent, improved on its predecessor ocaml-shout, but might not have been tested that much with shoutcast). I'd also be interested to hear if you can get segfaults with a different output. Cheers, -- David ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Savonet-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/savonet-users
