[Alsaplayer-devel] New AlasPlayer player module (fwd)
Andy Lo A Foe
Mon, 6 Dec 1999 00:11:03 +0100 (MET)
---------- Forwarded message ----------
Date: Sun, 5 Dec 1999 15:38:06 -0600 (EST)
From: Steven Feil <email@example.com>
Subject: New AlasPlayer player module
I'm looking to do some coding for a GPL project. I'm not sure if I
would be better off working with AlasPlayer or a program called
Snd. Having seen AlasPlayer here is what I like about it.
1. the sample tracker stays in sync with the sample. The is because it
takes advantage of ALSA. I've seen a few OSS based programs and there
sample trackers are way off.
2. AlasPlayer plays large samples directly from disk.
3. With AlasPlayer the user can easily play sounds at rates other than
they were recorded at.
4. AlasPlayer is dynamic, it responds imminently to users actions, such
as a change in sample position or playback rate is changed.
5. The AlasPlayer system is modular, which usually means that one
module can be developed without interfering with the rest of the
Some of the scopes look really cool, but I wanted to know if it was
possible to make modules that could be used for serious analysis
instead of just eye candy?
I've been thinking about module that would allow a user to slice up a
sound sample and play back the slices in any order. As an example,
seconds 1.2 - 4.5 could be played from a sound sample then seconds
90.4 - 103.2 could be played followed by 30.4 - 63.7. This would be
done in real time. The original sample would be untouched. This would
allow the user to easily reposition the stops and starts until they
are just right. The stop and start data could be saved and a new
sample could be generated from the old sample.
The ability that AlasPlayer has to play slow and backwards and
reposition would make it easer for the user to find the exact position
that he/she needed. I just don't know if the AlasPlayer's interface
between the main player and the modules allows for the type of
communication needed. Here is what my module would require.
1. My module would also have to receive data on a timely basis concerning
the current play position.
2. My module would have to know the name of the sample, so that it
could load in data to produce a graph of the whole sound, or a reason
sized chunk. By producing a graph of the sound, the user would have
some idea of where the stop and start points are being placed.
3. The biggest question would be, can the main player receive request from
the modules to reposition the playback?
Thank you for your time.
Steven Feil | Gram-pa, back at the turn of the .~.
Programmer/Developer | century, why did people use an /V\
firstname.lastname@example.org | operating system, when they were not // \
| allowed to see the source code? (X_X)