I am having trouble reading the length of an .ogg file. Playback and other audiodata-reads work fine. I tested this with different mp3->ogg converters including audacity and the vlc-player regognizes the duration.
[java] OGGLoader loader = new OGGLoader();
AudioKey key = new AudioKey(file.getName(), true);
always -1
}catch (IOException ex){
}[/java]
The same problem:
[java] AudioNode musicSource = new AudioNode(ar, manager, "test.ogg", true);
musicSource.getAudioData().getDuration(); <
always -1 [/java]
Edit: Also setting a time-offset doesnt work - the file is always being played form the beginning:
[java] musicSource.setTimeOffset(currentTime);
if (musicSource.getStatus() == Status.Playing){
ar.stopSource(musicSource);
ar.playSource(musicSource);
}[/java]
Argh I have to correct my statement. Loading into ram is absolutely horrible for performance. Will streaming be revised? Like this I am not able to create a simple audio-player without performance issues.
Iām just a user in this case, too⦠but you canāt know the length of a streamed file without reading it all⦠so I think it is unlikely that streamed AudioNodes will ever be able to tell you their length.
I do a mix of streamed and non-streamed ogg files without any performance issues. What are you seeing?
Thatās pretty crazy sounding. Iāve never seen anything like that, though my non-streamed oggs are not quite so big.
I think regular audio players probably seek ahead through the file first. JME has to contend with several layers of indirection in this case since all the audio engine gets from the asset manager is an InputStream.
ā¦this is also why streamed audio cannot be replayed or looped in JME. The InputStream is done and there is no way to reset it.
I added long ambient loops to mythruna and went through great (well not so great) pains to loop my streamed media. Good times.
ā¦by the way, are you running against a JME nightly build or an āolderā version?
I am running always newest nightly builds. However I now abandoned the timeslider and time-offset functionalities, using streams again. The looping I got to work by running a thread, checking wether the source is playing. I attached my whole JME-Musicplayer class, in case there is any need for it. The Playlist consists of the custom class MusicFile(Leaf), which can be contained by MusicCategory(Composite). I would also be happy to know, if I am violating any best practices, since I am new to jmonkey
.
[java] public class JMEMusicPlayer implements IMusicPlayer {
protected AssetManager manager;
protected Listener listener;
protected AudioRenderer ar;
private boolean repeat = false;
private boolean shuffle = false;
private ArrayList<MusicFile> playList = new ArrayList<MusicFile>();
Adding seeking support to the AssetManager would be very difficult.
For files it is quite easy, but for HTTP, you need to implement your own system to do it.
For JAR/ZIP/Classpath based sources, its not possible without decomressing the whole file entry first.
All this means is that its impossible to add seeking support on the input stream level. It has to be done manually in the audio system.
This leaves only one option, read the whole file first and then cache it in an efficient format so that it can be seeked by the Vorbis decoder.
For WAV, this is not possible without reading the whole file. So if you have a 30 MB WAV file and you stream it, your memory usage will increase by 30 MB.
Iāll see what I can do in regards to OGG ⦠Possibly you will have an option like āenable cachingā which will allow looping, seeking, and determining length of streaming OGG files at the expense of having to load the entire (encoded vorbis) data into memory.
I added a new āstream-cacheā feature to SVN. Use the new AudioKey constructor that takes two boolean arguments and pass ātrueā for both of them. You can now access the duration parameter.
It takes about 200 ms to load the OGG file from disk in that mode, but if youāre streaming it from HTTP it takes much longer (10+ seconds) because the file must be downloaded entirely.