Open
Bug 1134263
Opened 10 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)
Tracking
()
NEW
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).
Comment 1•10 years ago
|
||
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.
Updated•10 years ago
|
Blocks: gecko-games
Updated•9 years ago
|
Component: Audio/Video → Audio/Video: Playback
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•