Change `outputLatency` and `getOutputTimestamp` when `resistFingerPrinting` is enabled
Categories
(Core :: Web Audio, enhancement, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox70 | --- | fixed |
People
(Reporter: padenot, Assigned: padenot)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
In bug 1324552 and bug 1324545, outputLatency
and getOutputTimestamp
can expose the audio output latency of a particular setup (computer+audio hardware+driver combination).
In general, in Firefox, the audio output latency is fixed for each OS. However, in some cases, it can be different:
- If the audio output is routed to a higher-latency device (such as a bluetooth device), the number can be higher
- In the future (after we implement it), on Windows 10 with recent driver, the latency can be lower
- If the user has tweaked some hidden prefs in about:config, this can change also
I was going to report a fixed output latency (that is sensible) for those number when resistFingerprinting
is enabled. This means that some Audio/Video sync will be off when using bluetooth, but strictly better still than when we didn't have those attributes. This does not affect regular audio/video playback, nor webrtc, it's for more advanced scenarios.
Tom, does this sound good?
Comment 1•6 years ago
|
||
That sounds, great, thanks so much for flagging this.
Assignee | ||
Comment 2•6 years ago
|
||
Updated•6 years ago
|
Comment 4•6 years ago
|
||
bugherder |
Updated•6 years ago
|
Assignee | ||
Comment 5•6 years ago
|
||
Wrong bug number in a follow-up.
Updated•6 years ago
|
Assignee | ||
Comment 6•6 years ago
|
||
When Firefox is configured to resist fingerprinting, the latency figure returned
is the most commonly found on a particular OS.
For Android, I got data from 0, roughly copy/pasted the table into a file and
did:
cat file | cut -d $'\t' -f4 | grep "^[[:digit:]]" | cut -d ' ' -f 1 | sort -h
| uniq -c | sort -h
which indicated that 40ms was a good number for round trip latency (input to
output). Since this is for output latency only and the audio path
is roughly symmetrical in terms of duration, we report 20ms.
For OSX, 512 is always used with the default hardware in Firefox, with this
patch, it's always 512 regardless of the setup.
On Linux/Pulse, we use 25ms 1 always, and this is adjusted by PulseAudio. This
makes it always return 25ms.
On Windows, there is a wide variety of configurations, but it's common to be in
the ballpark of 80ms output (this is very empirical, by testing a bunch of
hardware over the years).
For other OSes, we use 1024 frames (adjusted to the sample-rate).
Comment 8•6 years ago
|
||
bugherder |
Description
•