Hi, On 1/8/07, arnaud guinvarch <[EMAIL PROTECTED]> wrote:
Looking at Savonet, I believe that it could be a very good tool to build this automated brodacasting tool. As such, I would like to know if you would know some skilled developers that could help me in the very next future.
First, Savonet is the name of a team, I guess you're refering to our stream generator Liquidsoap as the very "very good tool to build" your project. I want to make this clear in case you looked too quickly at our website and just saw our initial project (featuring many components, from the website to an intelligent database manager). This vision didn't last long, and we mostly only have liquidsoap left -- and a couple of small utilities. However, I do think that liquidsoap is a good tool to build a netradio. It's generic, clean, and will allow you to add more features easily. The project is still alive, although moving rather slowly, in an irregular way. The development team is quite small, compared to the initial team -- savonet used to be a school project. I'm the only one who knows liquidsoap's guts, and only three/four of us are still working on the project in general (libs+tools). All of us are phd students in computer science and none wants to give up on that, or dedicate more time than currently to the project. If you need somebody to help you to use liquidsoap, you don't need to look too far: using it shouldn't be too difficult. Also, this mailing list is there for help. My advice would be to look with somebody with experience in functional languages (in particular OCaml) since liquidsoap is influenced by them: the script language is functional, statically typed with inference. Knowing OCaml can also get handy if you need new features or fixes quickly. With more details regarding your needs (new features or mostly support) and employment offer I could ask a few people around me if you wish. I take the opportunity of this mail to declare that liquidsoap is quite stable if you avoid a few known issues: * RTP is not stable. * Alsa I/O depends on your hardware, AO seems to be a good replacement for ouptut but we have none for input. * Downsampled vorbis output eventually causes an unexplained exploding memory consumption. We've been warned that our downsampling code sucks so I expect to fix that when moving to the being-interfaced-with-OCaml libresample, but I'm not sure of anything. * There has been little testing other than on linux/x86. An endianness bug in ocaml-lame is still open on OSX/PPC. I hope you'll enjoy it! -- David
