Getting version 2.0 out!
========================

I need to get the reworked code out there. What are the hard points that prevent calling it usable?

- documentation of new features and changes (API)
- write a minimal man page
- check usage of inchannel::sync_state()
- Change dummy to be of endless length ... it can be useful as timer; as long as I don't have output timing at all.
- Put basic tools into some namespace, names like "thread" are really too general and likely to conflict ... heck what about mutex on Solaris, wasn't there a conflict with some macro? That wouldn't change via dmd::mutex ...

Individual tasks
================

Interactive speedup
-------------------

Disposable actions are implemented.

An Idea to minimize communication overhead: Store a quick-list of readlily-parsed actions and have the client say "repeat action x", perhaps just by sending number from 0 to 9 through the socket (hm, wouldn't help that much if it is a pipe with 16K buffer anyway). But the parsing and validation of the actions would the avoided.



Multiple output device synchronization
--------------------------------------

This is a rather basic feature the daemon should support, from its inception, actually: Ensure that different output devices can be used together. This needs to handle differing output clocks.
Handling a known clock skew is easy: Adjust playback speed (the most complicated part is integrating this with a choice for cheap builtin resampler or more sophisticated external code, also ensuring that resampling is not done twice without good reason). More tricky is the correct detection of the skew.

For that one needs timing info about the outputs. Currently, we work in a blocking way, writing the filled buffers. One could diagnose the time interval between finished writes... check if the time difference between different output channels is growing... this needs thought and testing. Also, people have done this before.


Position fixup
--------------

My position handling doesn't cover resampling, I suspect. Especially dropping of a buffer doesn't seek back to the proper position. I suspect.


Volume smoothness
-----------------

The follower smoothing brings up that one: When I realize volume ramps via changing the fixed amplification between buffers, I introduce jumps. Perhaps I'd like to do some smoothing for the volume, too?
Something like storing the old volume at the end of the previous buffer, then scale that towards the new volume during a certain amount of samples.

And: Really get down to jusitfy the smoothing for followers. Was this motivated from some really observable clicking? I have to wonder, as my prime follower example doesn't get a difference from the smoothing and sounds just fine.
The follower smoothing is being removed now... if ever, it will come back with the general buffer boundary smoothing.


Sub-buffer accuracy / control
-----------------------------

More new stuff: Hack accuracy of scripted start/pause, by taking care of the sub-mixerbuffer level via device buffer manupulation, filling with zeros from the beginning or end.
The simple approach for that would enable basically accurateness near one sample, but keep the granularity of one mixer buffer between distinct actions.

A more elaborate approach could also insert silence in between, handling extremely fast start/pause/start ... or smoother volume ramps.
Hm. Might be interesting. But might also be too much work to be worth it.


CPU statistics
--------------

Nice idea: After having structured threading stuff, collection of CPU usage per thread is becoming possible, at least at program end. Have a look at getrusage(), which gives per-thread user/sys time on current Linux systems at least.


Audio grabber?
--------------

Another interesting feature would be to be able to register as output device... grabbing the audio data.
Have to think there about some possible extensible buffer thread (or something) that prevents the main playback from halting because of the data sink is sleeping.


Do not use exceptions for real... or just use them.
---------------------------------------------------

Current code is not clear about it not wanting exceptions (like, using new(nothrow), compiling with -fno-exceptions -- which doesn't help you a lot because the C++ library _will_ throw exceptions). But it surely does not do anything with them. Program will crash, simple as that.
I need to change that. Either start using exceptions "properly" (I need to find a sane definition for that), or do it right without them. That includes the non-throwing new operatior (and handling of NULL return value... though memory failure will usually manifest in segfault later, on Linux in default config at least), but more importantly securing the constructors to never fail. Two-stage construction everywhere (I have some incarnations of that already).


Enhance scripting convenience
-----------------------------

edit script list (not just clear and rebuild)
... or not? A client could do that, too... Question is if re-parsing of retrieved script actions on client side is needed and breaking a rule of duplication. But then, the half-witted command-line client does partial parsing of command input, too.

In any case, that's a business for a time with no serious problems. For now.


Add suspend mode and unloading
------------------------------

It should be possible to send "suspend" to issue closing of all real-time devices (freeing /dev/dsp). The daemon should sleep then in long intervals until resurrected or better wait for a semaphore - outside action loop to allow a different client to issue the wake.

That might be a point for re-adding start/stop for outputs, with the meaning of actually open/close, but keeping the info about opened file there.

Already done is nice inactive sleeping when there is nothing to play (apart from constant nullsound on oss output... ). Everything else would be nasty, of course.

But wait: Is this closing/re-opening business of the daemon or of the client? I don't want unnecessary feature creep.


More testing
------------

I have some tests in place, at least. But more is needed.


****


Always in mind:


More Input and Output
---------------------

Update: ALSA and MME(Tru64) coming in 1.1.

libaudiofile, ogg, filewriter (wav, mp3), alsa, ...


Hunt down memory leaks!
-----------------------

I had the big hunt a while ago with leaking in the communication process... Besides the vmsize on newer Linux systems running up like crazy, I managed to get the "real" size more to the ground.
Now (December 2005) I again spot slow increase in resident memory (Kilobytes over hours)... One should have an eye on these. Everytime.

Hm, anything new on that front?
