-
Notifications
You must be signed in to change notification settings - Fork 6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Noise when playing FLAC content #6601
Comments
I'm facing the same issue after an update of Exoplayer to 2.10.5 version. |
I think this part is working as intended assuming you are playing audio in a .flac container file.
Looks like we need to switch to NDK 20, which also requires using c++_static not gnustl_static. I will make the fix.
Still investigating this. |
- Fix FLAC extension build (currently broken due to use of std::array, but fixed by migrating to NDK r20). - Move opus and ffmpeg extensions to NDK r20. For ffmpeg, upgrade to release 4.2 which requires using libswresample and updates to the build script. Issue: #6601 PiperOrigin-RevId: 277924119
Look at this comment in #6608 for a potential cause and fix for the one you are still investigating. |
As mentioned in #6608: I think the issue is probably that the audio sink is not reconfigured despite the PCM bit depth changing. When I was fixing this I uncovered another issue with draining audio processors which I'm looking into at the moment (this additional issue prevents this working even with a fix not to keep the codec). |
Note: - Fixing this uncovers another bug in how audio processor draining works, so the test playlist still doesn't play correctly after this change. - Once we reconfigure the audio sink based on the ExoPlayer Format rather than the codec MediaFormat in a later change, this change can be reverted. Issue: #6601 PiperOrigin-RevId: 281264149
Note: - Fixing this uncovers another bug in how audio processor draining works, so the test playlist still doesn't play correctly after this change. - Once we reconfigure the audio sink based on the ExoPlayer Format rather than the codec MediaFormat in a later change, this change can be reverted. Issue: #6601 PiperOrigin-RevId: 281264149
This simplifies the contract of configure and is in preparation for fixing a bug where more input can't be queued when draining audio processors for a configuration change. Issue: #6601 PiperOrigin-RevId: 282514367
Issue: #6601 PiperOrigin-RevId: 282515179
flush() is guaranteed to be called in all these cases anyway. Also clarify documentation for AudioProcessor-specific methods that can change the 'active' flag. Issue: #6601 PiperOrigin-RevId: 282515255
When transitioning to a new stream in a different format, the audio processors are reconfigured. After this, they are drained and then flushed so that they are ready to handle data in updated formats for the new stream. Before this change, some audio processors made the assumption that after reconfiguration no more input would be queued in their old input format, but this assumption is not correct: during draining more input may be queued. Fix this behavior so that the new configuration is not referred to while draining and only becomes active once flushed. Issue: #6601 PiperOrigin-RevId: 282515359
This simplifies the contract of configure and is in preparation for fixing a bug where more input can't be queued when draining audio processors for a configuration change. Issue: #6601 PiperOrigin-RevId: 282514367
Issue: #6601 PiperOrigin-RevId: 282515179
flush() is guaranteed to be called in all these cases anyway. Also clarify documentation for AudioProcessor-specific methods that can change the 'active' flag. Issue: #6601 PiperOrigin-RevId: 282515255
When transitioning to a new stream in a different format, the audio processors are reconfigured. After this, they are drained and then flushed so that they are ready to handle data in updated formats for the new stream. Before this change, some audio processors made the assumption that after reconfiguration no more input would be queued in their old input format, but this assumption is not correct: during draining more input may be queued. Fix this behavior so that the new configuration is not referred to while draining and only becomes active once flushed. Issue: #6601 PiperOrigin-RevId: 282515359
This should be fixed in the |
Question
Initially this was opened as a bug here, but after much further investigation, it appears to be an error on my client or server side.
Using ConcatenatingMedia and a MediaSources which are a mix of 16bit and 24bit music tracks, static and noise appear when switching from certain 24bit sources to 16bit sources. This happens when switching from 44.1KHz/24bit source to any 16bit source.
During the static, following error is repeatedly logged:
AudioTrack: Discontinuity detected [expected 'some value', got 'some other valuej']
I've found out that LibflacAudioRenderer returns FORMAT_UNSUPPORTED_TYPE when supportsFormatInternal method is called. That is because format.sampleMimeType is "audio/raw". Therefore FlacDecoder is never created. Any advice?
And for additional info, here's my ExoPlayer construction:
Creating RenderersFactory instance. (I've tried various options here, all lead to same results).
Creating MediaSources for ConcatenatingMediaSource:
EDIT:
Playback is normal when I downgrade to 2.9.x ExoPlayer. So perhaps this really is a bug. Any way to make this work on Exo 2.10.x ?
EDIT2:
I am also unable to build FLAC libs on 2.10.6 version.
A full bug report captured from the device
logcat.txt
Link to test content
Test content sent to [email protected].
The text was updated successfully, but these errors were encountered: