Audio on Demand
The objective of this project is to develop a flexible and extendable
Audio-on-Demand system for classroom use. It should follow most of
these guidelines:
* Modular - We want to start with a simple implementation, that will
provide basic functionality. The design should allow for
extending functionality in the future, including, perhaps,
video.
* Weighted toward server - Complexity should be centered at the server,
whenever possible. Since we want the client to be available on=20
different platforms, it needs to be simple. This is not always
possible, because issues of loss and buffering can only be dealt
with at the client side. Availability and usefulness for client-side =
=20
decoding API's will affect this decision when migrating to video.
* Complying with standards - Whenever possible, use standard =
implementations
for the job (for example, MPEG1-System for audio delivery). If=20
time or expertise is an issue, make room in the design
for future implementation.
* Available tools - Whenever possible, use available tools for the job.
Available audio players and web-based communication are good
examples. This is also only a guideline.
Stages in Functionality
Development needs to be done in stages, as time and resources become
available. However, we want to supply some functionality at each stage.
Here are general demarkations:
1. Bursty delivery of audio segments in the file. The audio is stored
on the client side and played with a local audio player. This is=20
a request/response transaction, with no state required in the client
or server.
=20
2. Bursty delivery of audio segments, but the server keeps track of
the client's position in the file. This means that the client can
request the 'next' segment from the server. This also means that
the client has to stay up and communicate with the server, which
will probably require a GUI client.
3. A realtime playback of audio. Since we want this model to be standard
and expandable, the transport mechanism for this service should be
one used by industry (e.g. MPEG-System), and preferably support
video. I would guess that most of the work will go into this part.=20
Scenarios
Stage 1: The audio file is indexed by topics/segments. The links to=20
the indices are placed on a web page. Each index is a small=20
text file on the http server. When a user clicks on an index
link, the http server returns that index file. We can MIME type =
=20
the index files, so that when the client gets the index file
back, it will automatically launch the AOD client application
with that index file(1). The index file contains information =
like
the AOD servername, audio file path, segment offset, segment =
size,
and audio format. The client relays this information to the
AOD server, which transfers that audio segment back to the
client. The client stores the audio in a temporary file, and
launches a local audio player to play the segment.
A specific example of this would be real-time notation =
associated=20
with hypertext links for replaying audio files starting at=20
a specific time.
Stage 2: Same as above, except that the client has a user interface.
Once the client is launched, the user can communicate with
the server and get the index list locally, go to the next =
segment,
or to go to any segment in the list. Then the client downloads
that segment and launches the audio player.
Stage 3: Same as above, except that audio need not be stored. Audio is
read directly from the network and played.
-------------------------------------------------------------------------=
-
(1) Thanks to Adam Arrowood for the idea
=20
------------- End Forwarded Message -------------