Yo list, As I am thinking about finishing the new clock system in liquidsoap, I'm facing a difficult choice. A new thing that I want to support is the dynamic creation (and removal) or outputs. When you know what clock owns the output, and that clock is already running, it's easy. When you don't, it's really tricky.
Currently a liquidsoap config goes through several steps: parsing, type-checking, construction, initialization. Type-checking notably infers the type of streams (audio, video, number of channels, etc) and clocks are only infered at the construction of sources. Finally, at initialization, sources which don't have a clock yet get assigned to the default clock, then all clocks are started, which starts the outputs and finally their sources. This system doesn't apply naturally for the dynamic creation of sources. It's easy to parse, type check and run code dynamically, but when do we initialize the dynamically created sources (which includes assigning the default clock when needed)? In a sense, I'm asking how to get rid of the initialization phase, which is the last thing that makes the initial script any different from runtime-executed scripts. If we succeed then liquidsoap could become much more dynamic. One idea is to initialize every now and then, at least after each scripting execution, but probably also during code execution. It has one little disadvantage: some outputs could start before others, e.g. a file dump might start a little later than the icecast output of the same stream. But it has a bigger disadvantage: if we initialize too early, a source could get attached to the default clock, when it could have been intended for use in a particular situation involving another clock. A cheap solution is to have an explicit initialize() function that would trigger the clock-inference and initialization of new sources. It could be implicit after loading the initial configuration, so it would only be ugly for power users. We could also implicitly initialize after code executions, initial loading or not, then the problem would only remain for very complex code like services involving loops that wait on events and create outputs every now and then -- in such cases, one could still explicitly run initialize() explicitly. I realize I'm probably talking to myself here, but it helped, and you might want to share some thoughts. If you're interested and you find my text too obscure, I can develop a few examples. 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-devl mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/savonet-devl
