#343: Dynamic creation of outputs
-------------------------+--------------------------------------------------
Reporter: lukas | Owner: mrpingouin
Type: Feature | Status: new
Priority: 3 | Milestone: 1.0
Component: Liquidsoap | Version: 0.9.1+svn
Resolution: | Keywords: server telnet icecast output source
Mac: 0 | Linux: 1
Netbsd: 0 | Other: 0
Freebsd: 0 |
-------------------------+--------------------------------------------------
Comment(by mrpingouin):
Replying to [comment:2 lukas]:
> Thanks for your quick reply. I'm trying to understand the code right
now.
> I'm having a hard time though, as I'm not used to the language...
It looks like you're serious about this, I'm delighted!
> I found that comment in the 0.9.1 code for the source#get_ready and
> source#leave methods, saying they have to be called from the Root
thread.
> In my understanding, these are the initialization/cleanup methods you
> mentioned. Am I right guessing this being the problem?
Yes, the root thread calls those methods to initialize sources. In
addition there is a separate method #output_get_ready to call after the
main #get_ready (which can be lengthy, so it's useful to delay some
initialization as close as possible from the beginning of the streaming).
So, in 0.9.1 it shouldn't be too difficult to modify the code to make your
system work. The root thread could keep track of the currently-used output
list, in order to notice the new items in the list, and initialize them
before using them. You could also modify the point when the output get
added to that list, so that it's started if the output loop started. A
mutex would probably be useful too. For removing outputs dynamically it
can be more tricky, because you probably want to make a difference between
a stopped output and an output which wants to be removed: my first thought
would be a special command for removing outputs (be they stopped or not).
> You mentioned the new concept of "clocks" in SVN.
> As I get it, they will replace the "root" thread,
> and so one would be able to start more than one "streaming loop".
Exactly.
> As I read the SVN code, it is not yet possible to create clocks after
startup.
Yes, that's true. In fact, we have two sorts of clocks. Some are somehow
passive, managed by an operator (this is the case of cross() or
resample()) which needs more liberty on the time flow of its source. This
kind of clock can probably be created dynamically without any problem. The
more common and intuitive kind are the root-like clocks (wallclocks) which
rely on a streaming loop in a separate thread: those are currently
initialized after the script is loaded, and this wouldn't be done
dynamically currently.
> Let me get that concept straight.
> You fire up liquidsoap, creating the initial clocks,
> adding the output sources and finally starting the clocks.
Yes.
> Once the system is running, you can create a new clock
> from whichever thread you are in (server thread),
> add output sources to it, do the initialization stuff,
> and start the new clock.
> When you want to get rid of it, you simply tell it to shutdown,
> forcing it to cleanup its sources and unregister with the system.
Yes, you could initialize the clock, which would initialize its active
sources (outputs). However, let me stress here that you don't necessarily
need a new clock for your dynamically created output: you could attach it
to the main wallclock (Root.wallclock) by default. This would leave the
problem of dynamically attaching a source to a clock, which requires the
above mentioned initialization mechanisms.
Having one wallclock per output means one thread per output which is
sometimes not the most efficient. On the other hand, having more than one
wallclock is a good idea, as it can spread the CPU use over multiple
cores.
> Please tell me, if I can be of any help for the implementation.
> And keep up with this amazing project.
That would be great. I have a feeling that you could come up with a
solution for 0.9.1 or 0.9.2. However, we don't plan to release feature-
extended versions of those, so it might not be useful for everybody. On
the other hand, if you come up with something for the SVN version, it's
more likely that I'll have to adapt it a little bit, but it would be put
on the SVN and so would be useful for everybody. By the way, after that
first patch, if you want to do more, you would be very welcome in the
developer's community.
--
Ticket URL: <http://savonet.rastageeks.org/ticket/343#comment:3>
Savonet <http://savonet.rastageeks.org/>
Let's program our stream !
------------------------------------------------------------------------------
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-trac mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/savonet-trac
