1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
|
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:
===============
|
