I'm logging the delta in number of samples (i.e. how much the seek value is "beyond" the duration value) and that number seems to regularly be ~205 samples on my machine. I'm not sure if this is indicative of something i.e. is this the size of the OS/browser audio buffer?
Context
I had an issue where I was storing the .seek() position and later setting it on the same audio file. Setting a seek that's beyond the duration of an audio file did not work (the file would not play) -- I have to resort (for now) to do seek % duration to set a value that works.
The Problem
I'm using Howler with a short 1 second file. I'm playing that file in a loop.
When I access the playback position using
.seek(), Howl will often report that the position is beyond the file's duration.In the example below, the file's
.duration()is 0.9999773242630385 while the value returned by.seek()will sometimes be 1.004263038548753Reproducible Example
https://gregsadetsky.github.io/howler-bug-report-looping-seek-value/
Reproduction Steps
The source code for this example is here.
Possible Solution
I don't know.
I'm logging the delta in number of samples (i.e. how much the seek value is "beyond" the duration value) and that number seems to regularly be ~205 samples on my machine. I'm not sure if this is indicative of something i.e. is this the size of the OS/browser audio buffer?
Context
I had an issue where I was storing the
.seek()position and later setting it on the same audio file. Setting a seek that's beyond the duration of an audio file did not work (the file would not play) -- I have to resort (for now) to doseek % durationto set a value that works.Howler.js Version
v2.2.4
Affected Browser(s)/Versiuon(s)
Google Chrome 119.0.6045.159 on macOS 12.7