search

google / ExoPlayer

This project is deprecated and stale. The latest ExoPlayer code is available in https://github.com/androidx/media
https://developer.android.com/media/media3/exoplayer
Apache License 2.0
21.74k stars 6.03k forks source link

Can FLAC Extension play 96kHz/24bit track without downsampling? #6643

Closed ivan2311 closed 4 years ago

ivan2311 commented 4 years ago

I'm using FLAC Extension to play .flac files and I have really basic ExoPlayer setup:

ExoPlayer exoPlayer = new SimpleExoPlayer.Builder(this).build();

public void playUrl(String url) {
            MediaSource mediaSource = new ProgressiveMediaSource.Factory(new DefaultDataSourceFactory(this, agent))
                    .createMediaSource(Uri.parse(url));
            exoPlayer.prepare(mediaSource);
            exoPlayer.setPlayWhenReady(true);
    }

.flac files are playing ok, but when I look at the audio output it shows that audio signal can't go above the 24kHz, it always gets downsampled. For testing purposes I have a 96kHz/24bit .flac file that is just simple audio signal that goes from 1kHz to 32kHz and I'm checking audio output with Audacity. And what I'm seeing is that signal never goes above 24kHz. Is this a bug in the ExoPlayer library since there is a commit that states that 192kHz should be supported: https://github.com/google/ExoPlayer/commit/0b0868889ec3caaa64579d0f3212229fc987a304? Does that mean that ExoPlayer downsamples everything that goes above 48kHz? Am I missing something here to support 96kHz?

Also, I've performed same test using Android MediaPlayer and it's ok, signal goes to 32kHz without any issues.

EDIT: ExoPlayer version: current dev-v2 version, with latest commit: https://github.com/google/ExoPlayer/commit/87003b30fce2860dc734025b00fcf06de8da4ded (I couldn't build FLAC extension with the latest release version release-v2 ). Previously I've used ExoPlayer v2.10.1 and it had the same issue Testing device: Sony Xperia XZ Other Audio equipment: external USB sound card (Steinberg UR28) to test output of analog (via on-device 3.5mm stereo jack) and digital audio signal (via USB audio through Steinberg UR28)

kim-vde commented 4 years ago

I tried to reproduce on a Pixel 2 on Android 10 with a flac test file containing a sweep going from 1Hz to 96kHz sampled at 192kHz.

I first examined the PCM data outputted by the FLAC extractor using ExoPlayer TeaAudioProcessor.java. The frequency still goes to 96kHz, which means that the FLAC extension is not responsible for decreasing the frequency.

I then examined the frequency received by the audio engine (audioflinger) and can confirm it received a 192kHz stream. As I do not have a USB sound card supporting 192kHz, I was not able to confirm whether the whole output chain is at 192kHz when such sound card is connected.

Note that the AOSP audio system does not open USB sound cards higher than 96kHz.

It is possible that Sony modified their MediaPlayer to force output at 192kHz when the source is at such sampling rate but did not change the code of AudioTrack. If that is the case, Exoplayer will not be able to workaround the issue as it uses AudioTrack and not MediaPlayer.

In order to better understand the issue, could you please generate 2 bug reports while playing your 96kHz audio FLAC on your USB sound card:

Make sure not to stop the playback until the bug report is fully generated (takes ~2 minutes).

How to take a bug report: https://developer.android.com/studio/debug/bug-report

krocard commented 4 years ago

Also, I've performed same test using Android MediaPlayer and it's ok, signal goes to 32kHz without any issues.

To clarify, have you observed a 32kHz signal on both the analog (on-device 3.5mm stereo jack) and the digital (USB) or just the digital interface?

ivan2311 commented 4 years ago

@kim-vde since you've tried this on your end and had no issues, a dig a little bit further into this problem and created even more simpler app that just plays sample .flac. And there was no issues, so it turns out it wasn't because of the ExoPlayer, but apparently something inside my app, which I'm still investigating.

@krocard I've observed on both interfaces.

@kim-vde @krocard Thanks for investigating this and helping me to eliminate ExoPlayer as the source of the problem. I'll close this issue for now...

ivan2311 commented 4 years ago

I'm reopening this issue with new info:

As it turns out, issue on my side was because of the Equalizer. If Equalizer is attached to the player, output always gets downsampled. So, removing Equalizer completely, solved problem but only on some devices...

Audio signal is OK (not downsampled):

Audio signal is downsampled:

As it turns out, only Sony and Samsung devices with 3.5mm stereo jack doesn't downsample.

krocard commented 4 years ago

Audio signal is OK (not downsampled):

Are those test done with Exoplayer or Mediaplayer?

To be able to tell if the issue has something to do with Exoplayer, or those phone just do not support 96kHz on their USB output, we need a bug report.

Could you please play your 96kHz test sound on USB and generate a bug report, please try to not change the audio state (aka do not pause, reach the EOF...) during the bug report generation (~3min). Thanks

ivan2311 commented 4 years ago

Are those test done with Exoplayer or Mediaplayer?

With ExoPlayer.

I'll generate bug report...

krocard commented 4 years ago

Note that outputting audio at 96kHz on an analog jack is probably not very compatible with cheap earphones. Speakers (especially cheap ones) are not design to handle such high frequencies (>24kHz) and they might produce unwanted non linearities in the audible frequency range (<20kHz). As a result playing > 24kHz on an analog output may diminish the sound quality instead of improving it. That is one of the reason most phone only support 24kHz (48kHz SR) on their analog output. So it is not surprising you only found support in a few flagship.

ivan2311 commented 4 years ago

Bug reports

With ExoPlayer: exoplayer_report_06122019.zip

With MediaPlayer: mediaplayer_repory_06122019.zip

This bug reports were generated while playing .flac test file via simple sample app. Sample app can play that test file via ExoPlayer or MediaPlayer, whichever is currently chosen. Test file is 96kHz/24bit .flac containing a sweep going from 1kHz to 32kHz. Sweep is repeating few times so that we have playback that lasts more that 3 minute, which is required to successfully report the bug. For testing device, I've used Pixel 3 XL, with OS 10. Sound was played trough USB-C output. To connect device to the audio equipment, I've used USB-C to 3.5mm adapter, that comes with the device.

Test results: when playing on USB output with this device, downsampling at around 24kHz happens on both ExoPlayer and MediaPlayer

krocard commented 4 years ago

Thanks for the bug reports, I will take a look later today.

To connect device to the audio equipment, I've used USB-C to 3.5mm adapter, that comes with the device.

Why use the USB-C to 3.5mm adapter and not your Steinberg UR28 USB input?

ivan2311 commented 4 years ago

@krocard sorry I forgot to mention that this new tests were all done using Scarlett Focuscrite 2i2 which doesn't have USB input, so I need to use USB-C to 3.5mm adapter.

But, also as I remember, Steinberg UR28 also didn't have USB input, so whenever I was testing output from the devices that only have USB-C, I had to use USB-C to 3.5mm adapter. Sorry if there was some misunderstanding.

krocard commented 4 years ago

From the bug report section (adb shell) dumpsys media.audio_policy:

The only supported sample rate of your USB audio device is 48kHz, thus the framework downsamples the track that was originaly at 96kHz (dumpsys media.audio_flinger):

Output thread 0x7a72a4d2c0, name AudioOut_1D, tid 1360, type 0 (MIXER):
  Sample rate: 48000 Hz // The output SR
   12-06 12:32:50.319 AT::add       (0x7a6332a700)          58     no   4338      25      35 A  0x000 00000001 00000003  \
96000  3   1  0  -inf     0     0     0  00000000  24000   24000 f         0        0       new
^~~~ The track sample rate

Please test with an USB sound card supporting 96kHz.

ivan2311 commented 4 years ago

@krocard thank you for checking. I can see that this USB-C to 3.5mm adapter supports only 48kHz.

Further more, I've created bug report with one device that is working (Sony Xperia XZ) and one that isn't working with ExoPlayer, but works with MediaPlayer:

Sony Xperia XZ


**LG V30**
- OS version: 9
- device 3.5mm output directly connected to the Scarlett Focuscrite 2i2
- **working correctly on MediaPlayer, downsampled on ExoPlayer**
- bug report:

Output thread 0xe7403740, name AudioOut_15, tid 1575, type 0 (MIXER): I/O handle: 21 Standby: yes Sample rate: 48000 Hz HAL frame count: 1920 HAL format: 0x1 (AUDIO_FORMAT_PCM_16_BIT) HAL buffer size: 7680 bytes Channel count: 2 Channel mask: 0x00000003 (front-left, front-right) Processing format: 0x1 (AUDIO_FORMAT_PCM_16_BIT) Processing frame size: 4 bytes Pending config events: none Output device: 0x8 (AUDIO_DEVICE_OUT_WIRED_HEADPHONE) Input device: 0 (AUDIO_DEVICE_NONE) Audio source: 0 (default) Normal frame count: 1920 Last write occurred (msecs): 72738 Total writes: 5289 Delayed writes: 0 Blocked in write: no Suspend count: 0 Sink buffer : 0xe7a39000 Mixer buffer: 0xe7a72000 Effect buffer: 0xe7a77000 Fast track availMask=0xfe Standby delay ns=3000000000 AudioStreamOut: 0xe8eac550 flags 0x8 (AUDIO_OUTPUT_FLAG_DEEP_BUFFER) Frames written: 10154880 Suspended frames: 0 Hal stream dump: Thread throttle time (msecs): 90 AudioMixer tracks: Master mono: off No FastMixer Stream volumes in dB: 0:-10, 1:-53, 2:-53, 3:-30, 4:-23, 5:-49, 6:-inf, 7:-18, 8:-29, 9:-96, 10:-30, 11:0, 12:0 Normal mixer raw underrun counters: partial=0 empty=0 0 Tracks 0 Effect Chains Local log: 12-10 10:53:03.504 CFG_EVENT_CREATE_AUDIO_PATCH: old device 0x2 (AUDIO_DEVICE_OUT_SPEAKER) new device 0x2 (AUDIO_DEVICE_OUT_SPEAKER) 12-10 10:53:03.547 CFG_EVENT_RELEASE_AUDIO_PATCH: old device 0x2 (AUDIO_DEVICE_OUT_SPEAKER) new device 0 (AUDIO_DEVICE_NONE) 12-10 10:53:04.441 CFG_EVENT_CREATE_AUDIO_PATCH: old device 0 (AUDIO_DEVICE_NONE) new device 0x8 (AUDIO_DEVICE_OUT_WIRED_HEADPHONE) 12-10 10:53:04.443 AT::add (0xe6fb6000) 0 no 945 9 A 0x000 00000001 00000003 48000 1 0 0 0 00000000 24000 24000 f 0 0 E7A39000 00000000 12-10 10:53:07.681 CFG_EVENT_CREATE_AUDIO_PATCH: old device 0x8 (AUDIO_DEVICE_OUT_WIRED_HEADPHONE) new device 0x8 (AUDIO_DEVICE_OUT_WIRED_HEADPHONE) 12-10 10:53:09.482 CFG_EVENT_CREATE_AUDIO_PATCH: old device 0x8 (AUDIO_DEVICE_OUT_WIRED_HEADPHONE) new device 0x8 (AUDIO_DEVICE_OUT_WIRED_HEADPHONE) 12-10 10:53:10.186 AT::remove (0xe6fb6000) 0 no 945 9 S 0x600 00000001 00000003 48000 1 0 0 0 00041D41 24000 0 f 0 0 E7A39000 00000000 12-10 10:53:11.449 removeTrack_l (0xe6fb6000) 0 no 945 9 T 0x600 00000001 00000003 48000 1 0 0 0 00041D41 24000 0 f 0 0 E7A39000 00000000 12-10 10:53:41.626 AT::add (0xe8eed780) 0 no 7353 57 A 0x000 00000001 00000003 96000 3 0 0 0 00000000 30752 30752 f 0 0 E7A39000 00000000 12-10 10:57:01.780 AT::remove (0xe8eed780) 0 no 7353 57 S 0x600 00000001 00000003 96000 3 0 0 0 0124F800 30752 0 f 0 0 E7A39000 00000000 12-10 10:57:15.224 removeTrack_l (0xe8eed780) 0 no 7353 57 T 0x600 00000001 00000003 96000 3 0 0 0 0124F800 30752 0 f 0 0 E7A39000 00000000

Output thread 0xe7783cc0, name AudioOut_D, tid 1569, type 0 (MIXER): I/O handle: 13 Standby: yes Sample rate: 48000 Hz HAL frame count: 192 HAL format: 0x1 (AUDIO_FORMAT_PCM_16_BIT) HAL buffer size: 768 bytes Channel count: 2 Channel mask: 0x00000003 (front-left, front-right) Processing format: 0x5 (AUDIO_FORMAT_PCM_FLOAT) Processing frame size: 8 bytes Pending config events: none Output device: 0x8 (AUDIO_DEVICE_OUT_WIRED_HEADPHONE) Input device: 0 (AUDIO_DEVICE_NONE) Audio source: 0 (default) Normal frame count: 960 Last write occurred (msecs): 50076 Total writes: 1361 Delayed writes: 0 Blocked in write: no Suspend count: 0 Sink buffer : 0xe8ec0000 Mixer buffer: 0xe8efe000 Effect buffer: 0xe7a3e000 Fast track availMask=0xf8 Standby delay ns=3000000000 AudioStreamOut: 0xe8eac730 flags 0x6 (AUDIO_OUTPUT_FLAG_PRIMARY|AUDIO_OUTPUT_FLAG_FAST) Frames written: 1306560 Suspended frames: 0 PipeSink frames written: 1306560 Hal stream dump: Thread throttle time (msecs): 0 AudioMixer tracks: Master mono: off FastMixer thread 0xe7703500 tid=1563 FastMixer command=COLD_IDLE writeSequence=13650 framesWritten=1310400 numTracks=1 writeErrors=0 underruns=4 overruns=1 sampleRate=48000 frameCount=192 measuredWarmup=17.1 ms, warmupCycles=5 mixPeriod=4.00 ms Simple moving statistics over last 7.8 seconds: wall clock time in ms per mix cycle: mean=4.00 min=0.65 max=9.75 stddev=0.33 raw CPU load in us per mix cycle: mean=283 min=0 max=1204 stddev=193 Distribution of mix cycle times in ms for the tails (> ~3 stddev outliers): left tail: mean=0.65 min=0.65 max=0.65 stddev=nan right tail: mean=9.75 min=9.75 max=9.75 stddev=nan Fast tracks: sMaxFastTracks=8 activeMask=0x1 Index Active Full Partial Empty Recent Ready Written 0 yes 656 0 0 full 1152 1305408 1 no 281 1 11 empty 0 53980 2 no 117 9 109 empty 0 18508 3 no 16 1 12 empty 0 3120 4 no 0 0 0 full 0 0 5 no 0 0 0 full 0 0 6 no 0 0 0 full 0 0 7 no 0 0 0 full 0 0 Stream volumes in dB: 0:-10, 1:-53, 2:-53, 3:-30, 4:-23, 5:-49, 6:-inf, 7:-18, 8:-29, 9:-96, 10:-30, 11:0, 12:0 Normal mixer raw underrun counters: partial=0 empty=0 2 Tracks of which 0 are active T Name Active Client Session S Flags Format Chn mask SRate ST L dB R dB VS dB Server FrmCnt FrmRdy F Underruns Flushed Main Buf Aux Buf FS 1 no 2700 17 S 0x600 00000001 00000003 48000 1 -inf -inf 0 0000D2DC 53980 0 f 0 0 E8EC0000 00000000 FS 2 no 1679 49 S 0x600 00000001 00000003 48000 1 -inf -inf 0 0000484C 2644 0 f 0 0 E8EC0000 00000000 0 Effect Chains Local log: 12-10 10:53:03.480 CFG_EVENT_CREATE_AUDIO_PATCH: old device 0x2 (AUDIO_DEVICE_OUT_SPEAKER) new device 0x2 (AUDIO_DEVICE_OUT_SPEAKER) 12-10 10:53:03.546 CFG_EVENT_RELEASE_AUDIO_PATCH: old device 0x2 (AUDIO_DEVICE_OUT_SPEAKER) new device 0 (AUDIO_DEVICE_NONE) 12-10 10:53:27.329 CFG_EVENT_CREATE_AUDIO_PATCH: old device 0 (AUDIO_DEVICE_NONE) new device 0x8 (AUDIO_DEVICE_OUT_WIRED_HEADPHONE) 12-10 10:53:27.333 AT::add (0xe6fb6a00) FS 1 no 2700 17 A 0x000 00000001 00000003 48000 1 -6 -6 0 00000000 53980 53980 F 0 0 E8EC0000 00000000 12-10 10:53:28.590 AT::remove (0xe6fb6a00) FS 1 no 2700 17 S 0x600 00000001 00000003 48000 1 -inf -inf 0 0000D2DC 53980 0 f 0 0 E8EC0000 00000000 12-10 10:53:30.086 AT::add (0xe8eed500) FS 2 no 1679 33 A 0x000 00000001 00000003 48000 1 0 0 0 00000000 2644 2644 F 0 0 E8EC0000 00000000 12-10 10:53:30.193 AT::remove (0xe8eed500) FS 2 no 1679 33 S 0x601 00000001 00000003 48000 1 -inf -inf 0 00000A54 2644 0 f 0 0 E8EC0000 00000000 12-10 10:53:31.716 AT::add (0xe8eed500) FS 2 no 1679 33 A 0x201 00000001 00000003 48000 1 0 0 0 00000A54 2644 0 F 0 0 E8EC0000 00000000 12-10 10:53:31.833 AT::remove (0xe8eed500) FS 2 no 1679 33 S 0x600 00000001 00000003 48000 1 -inf -inf 0 000014A8 2644 0 f 0 0 E8EC0000 00000000 12-10 10:53:34.811 threadLoop_standby: framesWritten:356160 suspendedFrames:0 monoPipeWritten:356160 monoPipeLeft:1152 12-10 10:53:34.811 threadLoop_standby: BOOTTIME offset 0 ExtendedTimestamp[0] position: 0 time: -1 ExtendedTimestamp[1] position: 356160 time: 38636144203 ExtendedTimestamp[2] position: 353808 time: 38649354359 ExtendedTimestamp[3] position: 356160 time: 38636144203 ExtendedTimestamp[4] position: 353616 time: 38645351078 12-10 10:53:34.922 AT::add (0xe6fb6c80) FS 3 no 1679 41 A 0x000 00000001 00000003 48000 1 0 0 0 00000000 3120 3120 F 0 0 E8EC0000 00000000 12-10 10:53:34.927 removeTrack_l (0xe8eed500) FS 2 no 1679 33 T 0x600 00000001 00000003 48000 1 -inf -inf 0 000014A8 2644 0 f 0 0 E8EC0000 00000000 12-10 10:53:35.109 AT::remove (0xe6fb6c80) FS 3 no 1679 41 S 0x600 00000001 00000003 48000 1 -inf -inf 0 00000C30 3120 0 f 0 0 E8EC0000 00000000 12-10 10:53:38.084 threadLoop_standby: framesWritten:504960 suspendedFrames:0 monoPipeWritten:504960 monoPipeLeft:1536 12-10 10:53:38.084 threadLoop_standby: BOOTTIME offset 0 ExtendedTimestamp[0] position: 0 time: -1 ExtendedTimestamp[1] position: 504960 time: 41914187223 ExtendedTimestamp[2] position: 502224 time: 41919843837 ExtendedTimestamp[3] position: 504000 time: 41894233420 ExtendedTimestamp[4] position: 501840 time: 41911850764 12-10 10:53:38.381 AT::add (0xe8eed500) FS 2 no 1679 49 A 0x000 00000001 00000003 48000 1 0 0 0 00000000 2644 2644 F 0 0 E8EC0000 00000000 12-10 10:53:38.384 removeTrack_l (0xe6fb6c80) FS 3 no 1679 41 T 0x600 00000001 00000003 48000 1 -inf -inf 0 00000C30 3120 0 f 0 0 E8EC0000 00000000 12-10 10:53:38.576 AT::remove (0xe8eed500) FS 2 no 1679 49 S 0x600 00000001 00000003 48000 1 -inf -inf 0 00000A54 2644 0 f 0 0 E8EC0000 00000000 12-10 10:53:41.261 AT::add (0xe8eed500) FS 2 no 1679 49 A 0x200 00000001 00000003 48000 1 0 0 0 00000A54 2644 0 F 0 0 E8EC0000 00000000 12-10 10:53:41.373 AT::remove (0xe8eed500) FS 2 no 1679 49 S 0x600 00000001 00000003 48000 1 -inf -inf 0 000014A8 2644 0 f 0 0 E8EC0000 00000000 12-10 10:53:44.357 threadLoop_standby: framesWritten:785280 suspendedFrames:0 monoPipeWritten:785280 monoPipeLeft:1728 12-10 10:53:44.357 threadLoop_standby: BOOTTIME offset 0 ExtendedTimestamp[0] position: 0 time: -1 ExtendedTimestamp[1] position: 785280 time: 48186688991 ExtendedTimestamp[2] position: 782352 time: 48194687012 ExtendedTimestamp[3] position: 784320 time: 48166398418 ExtendedTimestamp[4] position: 781776 time: 48182703158 12-10 10:57:15.161 AT::add (0xe8eed500) FS 2 no 1679 49 A 0x200 00000001 00000003 48000 1 0 0 0 000014A8 2644 0 F 0 0 E8EC0000 00000000 12-10 10:57:15.365 AT::remove (0xe8eed500) FS 2 no 1679 49 S 0x601 00000001 00000003 48000 1 -inf -inf 0 00001EFC 2644 0 f 0 0 E8EC0000 00000000 12-10 10:57:18.342 threadLoop_standby: framesWritten:933120 suspendedFrames:0 monoPipeWritten:933120 monoPipeLeft:1344 12-10 10:57:18.342 threadLoop_standby: BOOTTIME offset 0 ExtendedTimestamp[0] position: 0 time: -1 ExtendedTimestamp[1] position: 933120 time: 262171830680 ExtendedTimestamp[2] position: 930576 time: 262180596566 ExtendedTimestamp[3] position: 932160 time: 262152053284 ExtendedTimestamp[4] position: 930000 time: 262168777711 12-10 10:57:19.410 AT::add (0xe8eed500) FS 2 no 1679 49 A 0x201 00000001 00000003 48000 1 0 0 0 00001EFC 2644 0 F 0 0 E8EC0000 00000000 12-10 10:57:19.585 AT::remove (0xe8eed500) FS 2 no 1679 49 S 0x600 00000001 00000003 48000 1 -inf -inf 0 00002950 2644 0 f 0 0 E8EC0000 00000000 12-10 10:57:21.793 AT::add (0xe8eed500) FS 2 no 1679 49 A 0x200 00000001 00000003 48000 1 0 0 0 00002950 2644 0 F 0 0 E8EC0000 00000000 12-10 10:57:21.905 AT::remove (0xe8eed500) FS 2 no 1679 49 S 0x600 00000001 00000003 48000 1 -inf -inf 0 000033A4 2644 0 f 0 0 E8EC0000 00000000 12-10 10:57:22.992 AT::add (0xe8eed500) FS 2 no 1679 49 A 0x200 00000001 00000003 48000 1 0 0 0 000033A4 2644 0 F 0 0 E8EC0000 00000000 12-10 10:57:23.105 AT::remove (0xe8eed500) FS 2 no 1679 49 S 0x600 00000001 00000003 48000 1 -inf -inf 0 00003DF8 2644 0 f 0 0 E8EC0000 00000000 12-10 10:57:24.174 AT::add (0xe8eed500) FS 2 no 1679 49 A 0x200 00000001 00000003 48000 1 0 0 0 00003DF8 2644 0 F 0 0 E8EC0000 00000000 12-10 10:57:24.285 AT::remove (0xe8eed500) FS 2 no 1679 49 S 0x600 00000001 00000003 48000 1 -inf -inf 0 0000484C 2644 0 f 0 0 E8EC0000 00000000 12-10 10:57:27.272 threadLoop_standby: framesWritten:1306560 suspendedFrames:0 monoPipeWritten:1306560 monoPipeLeft:960 12-10 10:57:27.272 threadLoop_standby: BOOTTIME offset 0 ExtendedTimestamp[0] position: 0 time: -1 ExtendedTimestamp[1] position: 1306560 time: 271091675312 ExtendedTimestamp[2] position: 1304400 time: 271107270208 ExtendedTimestamp[3] position: 1306560 time: 271091675312 ExtendedTimestamp[4] position: 1304016 time: 271099270989


I can see in the LG V30 logs, that supported sample rate is only 48kHz so it should downsample, but **why it works on the MediaPlayer**?
krocard commented 4 years ago

I'm sorry but those dumpsys extract are not enough for me to understand the LG V30 audio configuration. I'm critically missing the Audio Policy dumpsys.

Could you please post 2 full bug reports (zip file like you did in https://github.com/google/ExoPlayer/issues/6643#issuecomment-562575964): 1) generated while playing with media player at >48kHz 2) generated while playing with Exoplayer at the same frequency (ideally the same file) I should then be able to compare the audio platform configuration to understand why the AudioPolicy chooses the 48kHz sample rate for Exoplayer output but not for MediaPlayer.

Also, it would be nice to disable the touch sounds, as they produce lots of audio event unrelated to our problem (settings/sound/touch sounds)

ivan2311 commented 4 years ago

@krocard here are 2 full bug reports:

  1. v30_mediaplayer_report.zip
  2. v30_exoplayer_report.zip
krocard commented 4 years ago

Thanks for the dumpsys @ivan2311, it let me figure out what is going on.

Without entering into too much details, MediaPlayer uses a special way of playing audio called "offload". It consists of not decoding the audio in the app and instead have the platform DSP decode it. It is a completely different audio path then the regular PCM playback. It has many restriction and is not suitable for most playback, but in your case, for this specific phone, audio format and sample rate, it allows the MediaPlayer to bypass the limitation of the phone PCM interface.

Basically LG's PCM interface (contrary to Sony's) has an artificial limitation to 4800kHz even though the HW supports other sample rates. This is not something Exoplayer or even the android framework can change, its forced by LG's configuration. By using offload, encoded FLAC is sent to a low level HW component (DSP) that decodes it without the 48kHz limitation as it does not go through LG's PCM interface but LG offload interface.

Unfortunately, this low level behavior is phone specific and can not be relied on across the ecosystem.

Note that offload APIs were made public in Android 10, so starting with Android 10, non platform player like Exoplayer can support it. Though Exoplayer currently does not.

krocard commented 4 years ago

To summarize:

ivan2311 commented 4 years ago

@krocard thank you for resolving this issue and the explanation!

Just one more quick question: if I'm playing HiRes 24bit track, should I enable conversion from HiRes int pcm to float inside DefaultAudioSink, since when it's set to false it converts 24bit pcm to 16bit, but I would like to have an unchanged 24bit at the output?

krocard commented 4 years ago

This question is unrelated to the main issue. Next time please open a new issue. Quick answer: playing high res samples is not currently supported by Exoplayer with MediaCodec. I juste open a feature request for it: https://github.com/google/ExoPlayer/issues/6749. Refer to its Alternatives considered section for workarounds.

ivan2311 commented 4 years ago

Thanks again @krocard !