echo "pause" > ~/.remoot/fifo

This is actually slightly more responsive than remoot (we are talking a few hundreds of a second here,
which may be important to some, but not to others). This is basically what remoot does for you as well,
but the "echo-method" does not start the daemon automatically for you. While this it is faster, the main
latency usually happens within the targeted multimedia app itself anyway, not ReMoot.



A client can look pretty much like anything.
Apparently.

The loop

daemoot keeps track on open and closed apps and passes arguments on to these. However, even
though it is running in the background, it does not monitor you apps continuously but remains passive
until you contact it with some argument. It then springs to life for a short while (a loop) and does
the following:

1. Recognizes the input argument

2a. It contacts amixer if the argument is about changing audio volume. Go to 5.

2b. If the argument is instead meant to control an app, daemoot checks what supported apps you
have open by parsing output from ps.

Q: What if I rename my apps to non-standard silly names?

Then you need to add these names as an alias in daemoot's library.

3a. It compares the list with the one from the last cycle to see if you have started a new one or not.
If you have, this is app will have priority (become dominating) and have the argument passed on
to it in the particular lingo it understands. Should you have more than one newly started app since
last time, the daemon will try doing the right thing and guess which one you are interested in
controlling (see below). The argument is passed on to it and all other apps you have playing are paused.
Go to 5.

3b. If there was no newly started application, the daemon will assign priority to whichever app had
priority (was dominating) in the last loop. Again, the argument is passed on to it, but this time only
if there are no playing non-dominating apps. ALSA's /proc/asound/timers interface is used to check this.
If such apps are playing, that means that you have activated it/them without using ReMoot, for instance
by manually pressing a button in a GUI. This is interpreted as if you want to switch over to control that
app from now on. If there are more than one such playing app daemoot will Do The Right Thing and
select one of them. The others are paused. Go to 5.

4. If the app dominating the last loop is not running anymore, the daemon instead looks for paused and
stopped apps (in that order) until it finds supported apps. If it finds only one it passes the argument on
to it and makes it dominating for the next round. If it finds more than one it will Do The Right Thing.
Go to 5.

5. It cleans up some data after itself, updates usage statistics and starts listening for input again. The
loop starts over.

Q: What happen if I play media that does not use ALSA, for instance a movie clip without sound?

Hehe, well... if it is not KDE app that has a DCOP interface, daemoot will actually believe that you have
stopped the app and that can potentially affect its decision-making in interesting ways :-p

Q: So daemoot does not notice what happens with apps in between loops?

Exactly, you can have an open/close-fest with your apps and unless you contact daemoot, it will have
no idea what has happened if you leave them in the same state as you began.

"Do the Right Thing"TM

ReMoot supports a lot of multimedia apps but assumes that you probably only want to control one app
at a time when you have more than one supported running. Apart from partitioning the applications
according to their status (new, dominating, playing/paused/stopped), as described above, the daemon
collects some simple usage statistics. Should it happen that the daemon needs to chose one among
several apps at any point in its loop, it will check these stats that it has compiled since it started:

• popularity - the number of times the app has received a command
• age - the number of uninterrupted loops the app has been found running

The daemon first checks the popularity and prioritizes the most popular app. If there are more than one
equally popular app it takes the older one. If there are more than one equally popular and old app, it
just grabs one of them, and you'll have no idea which one :-)

You can monitor the status and the stats of your apps by starting the daemon with the -v switch in a
terminal:

daemoot -v

When an app is targeted and passed an argument it gets top priority and becomes a dominating app.
A newly started app becomes dominant and removes the dominating status from the presently
dominating app, if any. The dominating app remains so until it is closed or until daemoot notices that a
non-dominating app is suddenly playing. When any argument is passed to a "freshly elevated"
dominating app, all other playing apps, if any, are paused.

---

Application support

daemoot keeps an internal library of instructions on how do handle each supported application.
The basic requirements for a program to be supported is that it supports some means of remote
controlling that can be automatized and is documented. Most supported programs have catchy
command shell one-liners that can be used, whereas others use DCOP, fifos, http or telnet.

Q: Why isn't my favorite program supported?

Maybe we have checked it and it does not support any means of remote access, or it is too poorly
documented to be implemented. Maybe we have forgotten about it or not even heard of it. File a
request to us in the latter case, and one to the developers in the former :-)

---

Performance

ReMoot is pretty responsive and should only add a few hundreds of a second on top of the time it
takes for the app to perform its action. If the app itself is very fast, like mpd och xmms, this overhead
might perhaps be noticeable to someone with an absolute sense of rhythm. If the app is slower, like
amarok, the overhead is minuscule. The time it takes for the daemon to issue a command is also
dependent on how many apps in total you have running on your system and how many supported
multimedia apps you run at the same time. If you need maximum oompf, we recommend the
"echo-method" described above over the "remoot-method".

You can run some bench-marking to assess the performance on your machine by starting the daemon
with the "-b" switch:

daemoot -b

It then uses Perl's standard benchmarking library. Since app instructions are launched as background
processes, you will get a feeling of how much overhead daemoot introduces. However, accurate
benchmarking of fast actions is very difficult. A more accurate way is presumably to remove the "&" sign
in the applications library in daemoot and instead time the total daemoot+app CPU time it takes to
complete the cycle. You then subtract the CPU time from that reported if you run the same instruction
to that app directly in a shell, without using the daemon. For instance like this:

time xmms -t

Q: How much memory does daemoot use?

Well, ehm, that is not easy to tell exactly. Doing ps aux reports an RSS usage of about 2.7MB and
a VSZ usage of about 6.5MB. A few megs. One more meg if it starts the telnet interface to SMPlayer
(which is less than starting telnet as a separate process).