When using the playbackrate attribute of the audio element, rates less then .5 are rounded up to .5. The attached example shows this in action. There are several buttons that playback the content at different rates. Playback rates for values from .5-2 are accurate. The page predicts playback duration for each button press based on audio duration/rate. Under .5 always yield actual durations approximate to predicted rates Over .5 always yield actual durations approximate durations based on a .5 rate. A casual listen to the audio at a ridiculously slow playback rate (say .1) will clearly sound like only half speed.
Created attachment 134083 [details] Html page and m4a file for testing the audio results in bug report.
Not all media engines are able to play back audio at arbitrary rates. In this case the lowest rate supported is apparently 0.5, so it is being clamped to that rate.
(In reply to comment #2) > Not all media engines are able to play back audio at arbitrary rates. In this case the lowest rate supported is apparently 0.5, so it is being clamped to that rate. Thanks for looking at this. Is playing at .5 the right behavior in that case? Wouldn't throwing an error be preferred?
(In reply to comment #3) > (In reply to comment #2) > > Not all media engines are able to play back audio at arbitrary rates. In this case the lowest rate supported is apparently 0.5, so it is being clamped to that rate. > > Thanks for looking at this. > > Is playing at .5 the right behavior in that case? Wouldn't throwing an error be preferred? There was a discussion about this about 18 months ago on the HTML5 mailing list. The spec editor feels strongly that a UA should do whatever tricks it has to to make it appear that playback is progressing at playbackRate, for example seeking and playing a snippet, seeking again, etc. A bug was filed against the HTML spec about this, but it was closed as WONTFIX. See http://www.w3.org/Bugs/Public/show_bug.cgi?id=10837 for a discussion. WebKit previously returned the actual playback rate, ie. the rate at which the media engine was playing, but because of the spec change it was updated to always return whatever value was last set.
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > Not all media engines are able to play back audio at arbitrary rates. In this case the lowest rate supported is apparently 0.5, so it is being clamped to that rate. > > > > Thanks for looking at this. > > > > Is playing at .5 the right behavior in that case? Wouldn't throwing an error be preferred? > > There was a discussion about this about 18 months ago on the HTML5 mailing list. The spec editor feels strongly that a UA should do whatever tricks it has to to make it appear that playback is progressing at playbackRate, for example seeking and playing a snippet, seeking again, etc. > > A bug was filed against the HTML spec about this, but it was closed as WONTFIX. See http://www.w3.org/Bugs/Public/show_bug.cgi?id=10837 for a discussion. > > WebKit previously returned the actual playback rate, ie. the rate at which the media engine was playing, but because of the spec change it was updated to always return whatever value was last set. Thanks for detailed response.