I'm estimating 0.14.0 will be one to two months out. Of course,
timelines are always subject to change. I'll try to update this
every few weeks here. Feel free to link or copy (with attribution)
to this in the wiki.
Do NOT consider the TODO distributed in tarballs or git to be accurate.
It'll be removed from the git distro very soon now.
0.14.0 TODO
-----------
* Cleanup and fix bugs introduced during the pthreads switch
and core rewrite.
* Fix ALSA CPU usage problem. We'll definitely need help gathering
information on this as no developer has a setup that can reproduce
the problem that I know of...
* Lower pthreads stack size where possible and safe to do so. The
current 2M default stack size from Linux NPTL is amazingly wasteful.
The 64K PTHREAD_STACK_MIN NPTL imposes is already more than sufficient
in most cases. Needs testing on 64-bit (also, keep in mind some
more exotic architectures use 64-bit ints as well as 64-bit longs).
* Merge published optimizations, cleanups, AAC streaming from Max.
* Hopefully merge tag database rewrite/memory reductions from Max.
* Merge shout_mp3 plugin. Needs cleanup.
* revamp inputStream and separate out transport layers
The goal of the inputStream revamp is to fully support asynchronous
operation and never block the main thread that talks to clients.
Currently, open() on a slow disk/filesystem (especially networked
ones) can be extremely sluggish.
+ There will be two distinct transport layers: HTTP and file
(this is nothing new)
+ A pure "peek" method will be supported
(a la pread() or recv()+MSG_PEEK)
+ open() methods will be non-blocking. This will have to be done
via pthreads for file transport. This is necessary for networked
filesystems (whether via FUSE, NFS or like).
+ All I/O methods will be cancellable (by dc_intr() or dc_seek())
+ read/peek methods will be always return the specified read
amount unless timed-out (stopping the decoder) or explicitly
cancelled. No partial reads will ever be returned. This should
clean up the decoders and remove my_usleep() entirely.
+ There will most likely be two runtime choices for file readahead:
1) read/write I/O with readahead using ringbuffer + pthreads.
This will be the most portable one, and will probably be
better all around if avoiding hard disk spinups is needed
on large FLAC files. pthreads will be needed anyways for
asynchronous open...
2) read/write file I/O with readahead done entirely with
posix_fadvise(). This is aimed at modern Linux 2.6 desktop
machines. Not many other OSes support posix_fadvise, yet.
- stdio routines will NOT be used for this any longer
+ HTTP readahead is also doable without threads on machines that
support large kernel-side buffers using large SO_RCVBUF settings.
Of course, the current pthreads+ringbuf code will continue to be
supported and improved for machines that don't support large
enough SO_RCVBUF.
* Configurable state_file updating. Unfortunately 0.14.0
will undoubtedly be less error-tolerant because of the switch to
threads; so the state_file is more important.
0.15.0 (early-mid 2009)
-----------------------
This only contains that are definitely going into 0.15.0. Depending
on the release quality of 0.14.0, this may come soon after 0.14.0.
* New commands to control replaygain/normalization.
(maybe 0.14.0)
* audio output (maybe 0.14.0)
+ while pausing, play silence for the devices that don't support
"pausing"
+ Per-audio output threads. These will all share a common
condition variable but each output will have its own mutex.
If at least one output succeeds in playing, then playAudio() will
return and continue.
* mixer (possible in 0.14.0, audio output improvements first)
+ allow binding mixers to a specific audio output
This needs to be done in a backwards compatible way for
volume changes.
+ allow mixers to be disabled when audio outputs are disabled
(for device disconnection)
* Listener protocol
Some (possibly obsolete/incomplete) documentation here:
http://mpd.wikia.com/wiki/MusicPlayerDaemonListenerProtocol
* NO_FPU support. Allow all internal time to be kept track of
in milliseconds, and things like software volume, replaygain,
normalization to be compiled out on machines that can't run
them anyways.
* AAC seeking (maybe moved to 0.14.0) if it's easy
* User-configurable arbitrary tags (maybe in 0.14.0 depending
on how Max's tag DB rewrite works out).
* Replaygain/normalization via "hardware" volume control
I think somebody was talking about this the other day but
this would help people on slow machines out a lot.
Post-0.15.0 (some of this is just copied from the TODO)
-------------------------------------------------------
* data structures
+ remove changes made to linked list for TagTracker (will probably
be done in 0.14.0 anyways).
+ cleanup linked list code (may be done in 0.14.0 or pushed back)
* Add support for 24-bit audio - need hardware for testing,
Could be pushed back if we don't have hardware or pushed
forward if we do...
* add error codes for status->error (from old TODO,
haven't looked into this yet)
* cleanup config file code (from old TODO)
* audio outputs
+ more accurate time reporting by determining how much of
audio_device buffer has been played. (from old TODO, not sure
if this one is worth it..).
* state
+ abstract out state code from playlist.c
+ put MPD Version in statefile
* mixer
+ OS X support (if somebody supplies a patch, I don't have a Mac)
* support for dynamically loading plugins
+ cleanup input plugins "API" (partially done by Max already)
+ cleanup output plugins "API"
I don't think a stable API nor ABI should be a goal, a consistent
one, yes. Linking to non-GPL-compatible code is not allowed and
should not be encouraged or made *easy*. Out-of-tree modules
(GPL-compatible or not) leads to quality control issues regardless
and should be discouraged.
* dynamic metadata, add support for
- last time played
- times played
- times skipped
- ranking
Need to consider memory footprint/overhead of adding these
to 30K song databases. It'll probably be optional for
embedded devices, and may be even done in a separate
daemon independent of mpd.
Probably Never
--------------
* add playlistreplace command
(replace current playlist with saved playlist and keep playing)
This was from the 0.14 TODO in the source tree, but is it really
needed? I don't see the need for this to be done atomically
since it'll likely end up playing new songs anyways.
* mixer
* add SUN support[1]
* audio output
* write a nas native audio output[1]
* write a SUN native audio output[1]
[1] - I'm not sure who cared about these in the first place, I haven't
heard much demand to support these and PulseAudio
should be able to replace NAS...
--
Eric Wong
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
