List of things that it'd be nice to do at some point.
Or random ideas that might not be so clever, but we havn't thought through
yet.

(Developers - feel free to add any random ideas you have to this file...
 Put your name by the idea so we know who to ask if we can't figure out what
 the comment in the file means.
 Only remove stuff if it's generally agreed that it wouldn't be a good idea.
 Patches to implement any of this stuff are [probably] gratefully received...)


Ideas from Richard Boulton:
===========================

a) Have sockmon monitor soundcard devices if you open the corresponding
   device file (ie, under /dev/, or even /proc/asound/) in the file browser.
b) Similarly have cdda play data on a CD if you open the corresponding device
   file.
c) Have a cdparanoia plugin, for people like me whose CD players a rather dodgy
   and don't happily read CDDA data.
   Cdparanoia sometimes goes slower than a real CD, so we might need to buffer
   lots of the CD, and only start, say, after we've got a minute of data
   buffered.
d) Have a plugin dialog, to select which plugins are currently in use, and
   what search path for plugins is.  Have ability to load and unload plugins
   at any time.  (Could compile up a new version of a plugin and insert it
   to fix a bug while alsaplayer is still running - might even speed
   development. ;-) )
e) Have ability to change DAC while alsaplayer is running.
f) Make a fully capable ncurses gui, for people who don't run X.
g) Pluginify the gui, so that we can have multiple different ones.  (Perhaps
   a gnome one, perhaps an ncurses one, perhaps a very plain one, etc...)
   (This is more than themeing...)
h) Make possible to specify initial playlists on the command line, even if
   using the GUI.
i) Have a monitor to show how much data is buffered between the producer
   process and the DAC  (would show when a socket monitor was running out of
   data / an mpeg player was running out of CPU time to fill the buffer.)
   User could then stop frobbing the processor quite so hard with other things
   in time to prevent there being (horror of horrors) a skip in the audio...
j) Have sound generation processes able to persist beyond the application
   closing.  Or at least, beyond the gui and the scopes closing.
   Then have ability to reconnect to an old process when application is next
   started.  Then I might be able to restart X without having to stop my
   music...
k) Have ability to have each item in a playlist fade into the next when it
   finishes.
   Will require all input plugins to have multiple simultaneous instances.
   Will also require that we have code to mix audio streams together.
   We might as well make this generic so that we can have multiple things
   playing at once...
l) Have "dummy" output driver, so that we can use alsaplayer to just listen to
   sound and display it on pretty scopes, without having to connect to a card.
m) Have ability to output to multiple sound devices at once. (eg, output to
   a soundcard, and an ESD on a remote machine.)
n) Have options dialogs for scopes, and input and output plugins.  Could do
   this by having each plugin have a set of attributes which can be set.
   Would add three calls to interface:
   	attribute_info() - returns a list of attributes, each item being:
		{internal_name, short_description, long_description, type,
		other_info}
	 . internal_name would be an identifier for the attribute used
	   in save files, etc.
	 . short_description would be used to prompt for the attribute
	   in dialog boxes.
	 . long_description would be a detailed explaination of the
	   attribute.
	 . type would be the type of the attribute.  eg - bool, range,
	   colour, other.
	 . other_info would be any extra information required, depending
	   on type.  Would probably be stored in a union.  eg: for a range
	   it would
	get_attributes() - gets the values of all the attributes, as a list.
	set_attributes() - sets the values of all the attributes, as a list.
   Using this scheme, all the burden of creating and managing the options
   dialog / loading and saving the options is put on the central code. (so
   keeps writing plugins easy)
   When each plugin is loaded, the main code will look for saved options in
   a configuration file.  If there are none saved for the particular plugin,
   then the plugin will keep it's default ones.  Otherwise, the main code
   will read the options from the configuration file and apply them to the
   plugin after it's init() call by doing a set_attributes() call.
o) Use URI's to specify what to play.  So we might have:
   http://host/mp3streamer     - to do a shoutcast thing
   cdda://<cddevice>/3-7       - to play tracks 3 to 7 on the CD
   sock_tcp://host:port/format - to monitor a TCP socket
   file:///<filename>          - to play a file
   Would default to assuming file:/// if wasn't in URI form, so that
   current stuff would all work.

Idea from Brian Hall (via alsaplayer-devel@lists.tartarus.org)
====================

I just paid $10 for the XMMS QSound plugin, since it dramatically improves the
sound of my MP3 on cheap speakers and headphones. I would love for alsaplayer
to have an "XMMS plugin" plugin- IOW a compatibility layer to allow using
binary-only XMMS modules in alsaplayer. Any chance of this happening, and is
it even possible?

Ideas from you:
===============