Open Bug 1134263 Opened 9 years ago Updated 2 years ago

Investigate using the same AudioStream when seeking instead of trashing it and getting a new one

Categories

(Core :: Audio/Video: Playback, defect)

x86_64
Windows 7
defect

Tracking

()

People

(Reporter: padenot, Unassigned)

References

(Blocks 1 open bug)

Details

This is what Chrome does, and seems like it could be worth it, creating and destroying system audio streams is expensive (and can be super super super _super_ long on some platforms, we've seen 8 seconds on OSX).
Yeah, this also allows us to do nice stuff like quickly fade the volume in and out during the seek so there's no harsh pop between sample transitions.

I think the only reason we have the current behaviour is that there's no API-level distinction between pause/resume (where we likely want to stop the audio stream for power/resource savings) and the type of short stream transition caused by a seek.  Maybe we need something slightly fancy, like a timeout on the stream where we only kill it after it has been paused/idle for more than N seconds.
Please add whiteboard:  [games]
Blocks: gecko-games
Component: Audio/Video → Audio/Video: Playback
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.