therewasaguy
commented
8 years ago @crhallberg thanks for the detailed bug report and test.
SoundFile.currentTime() goes back to zero once it reaches the max time. And currentTime can only be called during draw(). So it makes sense that there would be a difference between the highest currentTime you can read during the draw loop, and the actual maximum time (duration) of the file. The red line appears to be less accurate—when i run your test, it ends up outside the bounding box of the waveform. Are you seeing this to?
I'm going to close the issue because p5.sound has its own repo. Feel free to re-open this issue or related issues over here: https://github.com/processing/p5.js-sound/issues
A couple potential related issues:
- SoundFile.currentTime should not go back to zero after it reaches the end of playback. It should only go back to zero once play is called again.
- Performance issues with SoundFile.currentTime: In your test, the difference between any max currentTime reading and the soundfile's actual duration should not be more than the duration of one draw loop (~1/30 of a second or 0.033). So I'm a little concerned that in your screenshot, the difference is as large as 0.6 seconds. For me, the difference tends to be less than 0.01 if I only have one soundfile, but as I create more soundfiles, it gets higher. What is your frameRate and what browser are you using?
It's worth mentioning that the Web Audio API doesn't have any built in methods for getting the currentTime/frame of a buffer source node. And it was surprisingly difficult to implement currentTime that would be sample-accurate, even if the playback rate of a soundfile is changed. The current implementation is a hack that has some definite performance tradeoffs.
crhallberg
v0.4.17 - currentTime() doesn't exceed 92% of duration().
In the picture below, next to each waveform: track.duration(), the maximum track.currentTime() after playing twice, and the ration of maxTime/duration.
I discovered this bug playing around with sound recording: if I use currentTime() to draw a tracker while playing an audio file, it never quite reached the end. I found that it ends in between 90% (shorter files) and 92% of the reported duration(). In the picture above, the red bar (bottom track) corrects by 91.5% and the red line is much closer to the sounds' waveforms. The blue bar doesn't and is behind in each case. The first track is a sound file, the rest are recordings (using SoundRecorder) of microphone tappings.
Link to the sketch: https://www.dropbox.com/s/thyb0umynpe9sly/bug.zip?dl=0.
Hold down any key to record, click any sound to play it.