Sample rate converter lacks headroom and produces severe distortions on intersample peaks |
|||||||
Issue descriptionChrome Version: 60.0.3088.3 (Official Build) dev (64-bit) OS: Linux, Android, CrOS, not tested on Win and Mac. What steps will reproduce the problem? (1) Upload the attached "Sine 11025 ..." file to Google Drive, and use the Drive's audio player (2) Capture the output from the sound card (played via ODAC revB, captured on Focusrite 2i4) (3) Perform frequency analysis (in Audacity) What is the expected result? / What happens instead? This is a stereo file at 44.1 kHz containing a 11025 Hz sine wave phase shifted at 45 degrees, and normalized to 0 dBFS on the left channel, and to -6 dBFS on the right channel. When rendering this wave, the actual peaks that occur between samples go up to +3 dB above the sample values. When played via an output path that provides enough headroom, these intersample peaks can still be rendered. Whereas, if the output path doesn't provide headroom, these peaks get clipped, producing distortions. If this file is played using a native player app, there are almost no distortions (that actually depends on the DAC used, but in my case there are almost none). If this file is played using Drive Player in Chrome, the left channel gets distorted. When a 48 kHz file (containing a 12 kHz sine wave phase shifted and normalized the same way) is played, it is not being clipped. That's why we suspect the clippings occur in Chrome's sample rate converter. If volume is decreased on the Drive's player, the left channel is left undistorted as well. The full list of configurations we have tested: Linux: - Chrome 60, Drive, 44.1 kHz - clips (see Chrome-60.png) - Chrome 60, Drive, 44.1 kHz, reduced volume on Drive player - OK - Chrome 60, Play Music, 44.1 kHz - clips - Chrome 60, Play Music, 44.1 kHz, reduced volume in PM - OK - Chrome 60, Drive, 48 kHz - OK - Firefox 53.0 (64-bit), Drive, 44.1 kHz - OK (see Firefox.png) CrOS / ASUS Spin 11: - Chrome 58, Drive, 44.1 kHz - clips - Chrome 58, Drive, 44.1 kHz, reduced volume on Drive player - OK - Chrome 58, Drive, 48 kHz - OK Android N 7.1.2: - Chrome 58, Drive, 44.1 kHz - clips - Play Music app, 44.1 kHz - OK
,
May 9 2017
BTW, I forgot to mention that the DAC was configured in PulseAudio on Linux to 48 kHz. I tried changing the sample rate of the DAC to 44.1 kHz, and after restarting Chrome it now plays the 44.1 kHz sine track without clipping. So the problem is definitely with the sample rate converter.
,
May 10 2017
,
May 15 2017
I've rechecked Play Music on N5X, and it also clips when playing a 44.1 kHz file, but doesn't clip when playing a 48 kHz file. But I'm still not sure whether Chrome does resampling by itself or relies on the OS to do it.
,
May 15 2017
Doesn't seem like P1, since this code hasn't been touched since inception. The resampler is at media/base/sinc_resampler.cc if you want to dig in. I won't be able to take a look at this until probably next week or later.
,
Jun 17 2017
+flim, turajs in case they or someone else on the signal processing team wants to take a look or have opinions on this. We always resample to the system sample rate since it's required on some platforms (Win, MacOS) and may act oddly on others (Linux). When you have output configured for 48kHz we'll end up doing a sinc resample with blackman parameters using a kernel size of 32 from 44.1kHz. Probably we can increase the kernel size to make this perform better: https://cs.chromium.org/chromium/src/media/base/sinc_resampler.h?l=26 Do you know if the play music app is triggering resampling at all? I.e. is this a case of the native Android resampler being superior to the one in Chrome, or just a case of resampling being skipped entirely? We will resample to AudioManager.PROPERTY_OUTPUT_SAMPLE_RATE; which I think I've generally seen as 48kHz. We used to pass through the sample rate, but had issues with low latency applications. I think we have enough latency information available to allow passthrough on Android again.
,
Jun 30 2017
Play Music app is not resampling by itself. Depending on the track length, it can either be resampled by Android's audio system resampler (if the track is short it is played via "deep buffer" path), or processed entirely by the DSP (if the track is long, it is just being offloaded to the DSP for decompression). As I've noted in comment 4, Android's resampler actually lacks headroom as well. I've filed b/38313401 for this issue.
,
Nov 29 2017
,
Nov 29
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 29
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by mnaga...@chromium.org
, May 8 2017