We just swapped out the mp3 decoder library with a new one in order to fix these problems last week. You might want to give trunk a try, I think it should be much better. Mike On Oct 5, 2008, at 2:29 PM, Mark D. Anderson wrote:
I apologize in advance that I can't characterize this better than with some symptoms, praying that someone has some suggestions.
I'm running a fs-based system where people can call-in, type a digit in a simple IVR prompt, and then hear a chosen mp3 stream. This is implemented entirely in javascript. When the stream is chosen i call play_file("shout://domain.com/mount.mp3") or whatever.
It works most of the time. However, now with increasing users, it eventually starts producing garbled/slow audio. Once this starts, all users experience it, and the entire FS process has to be restarted to fix it. It is not starved for cpu or memory. There is no problem with the original streams; internet listeners don't have any problems.
So, it "feels" like a thread-safety/memory-corruption issue, but I'm not clear how much sharing is really going on -- presumably libshout is thread-safe, and little sharing actually goes on among sessions? It is quite possible that there are different mp3 encoding parameters (channels, bitrate, etc.) among the different streams being used, but again, presumably that context is not shared among sessions?
I've been getting desperate enough that I've been toying with the idea of decoding the mp3 streams myself out of process, and piping RAW bits directly into a unix domain socket, and playing that instead, bypassing libshout and lame entirely. (Would that work?)
I'm running svn rvn 9361, 2008-08-23. I'm building with --enable-core-odbc-support and have these languages and formats enabled: formats/mod_native_file formats/mod_sndfile formats/mod_shout formats/mod_local_stream formats/mod_tone_stream languages/mod_spidermonkey languages/mod_spidermonkey_teletone languages/mod_spidermonkey_core_db languages/mod_spidermonkey_socket languages/mod_spidermonkey_odbc languages/mod_lua