FINAL PROPOSAL: JavaSound extensions and service providers for Ogg/Vorbis and Ogg/FLAC
Tor-Einar Jarnbjo
tor-einar at jarnbjo.name
Sun Mar 2 16:42:58 PST 2008
* Proposed goals:
- Add JavaSound service providers for reading Ogg/Vorbis and Ogg/FLAC.
There are several RFEs touching this subject, e.g. 4671067, 6405350
and 4499904. I am not going to reinvent the wheel for this, but I
would refurbish the code from my J-Ogg project (www.j-ogg.de) and
donate it to the OpenJDK project. I beleive that J-Ogg is mostly
bug free, but the code base could need some refactoring and cleanup.
Some specific points to consider:
- add generics
- migrating to NIO may make it easier to support different datasources
- better abstraction of the different datasources, especially when
it comes to caching and positioning
- Extend AudioInputStream to optionally support positioning within the
audio stream.
To make JavaSound a feasible backing technology for e.g. simple media
(audio) players, AudioInputStream should support public methods for
positioning. Although this functionality is offered by JMF, it makes
sense to me, to offer such functionality in the standard J2SE API.
boolean AudioInputStream#isSeekable();
long AudioInputStream#getFramePos();
void AudioInputStream#setFramePos(long newpos);
The last methods acting on the protected field
AudioInputStream#framePos.
- Extend AudioFileReader to support further seekable sources for raw data.
Currently, AudioFileReader can read an audio stream from either a File,
an InputStream or a URL. This means, that to propagate "seekability" to
the AudioInputStream without much fuzz, the source has to be a File,
since InputStreams and URLs per se, are not offering a public interface
for positioning. In practice however, some InputStream implementations
are indeed seekable, e.g. ByteArrayInputStream and FileInputStream and
depending on the underlying protocol, InputStreams returned from URL/
URLConnection may be seekable as well. Positioning in the stream from a
file URL should always be possible, and utilizing the range header in
HTTP, positioning in the stream from an HTTP URL may also be possible
(and desired, e.g. for audio streaming over HTTP) if the server
supports that functionality.
Considering that positioning with a stream can be useful in many other
situations as well, my suggestion would be to either introduce a new
interface java.io.SeekableInputStream, or perhaps just as well add the
following methods to InputStream directly:
boolean ...#isSeekable();
long ...#getPosition();
void ...#setPosition(long newpos);
Having the methods directly in the InputStream class, would make it
easier for delegating implementations of InputStream to propagate the
functionality, e.g. if a seekable stream is wrapped by a
BufferedInputStream.
In InputStream, these methods would of course be implemented to return
false and throw UnsupportedOperationException, but as a starter, it
would be very easy to add this functionality to at least the following
classes:
- ByteArrayInputStream
- FileInputStream
- FilterInputStream
- BufferedInputStream
At some further point (it's not part of this actual proposal), it
should also be considered to add this functionality to the InputStreams
return by URL/URLConnection, if the protocol used supports positioning.
Regards,
Tor
More information about the challenge-discuss
mailing list