Skip to content
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

Closed
tomislavturcic opened this issue Oct 30, 2019 · 5 comments
Closed

Noise when playing FLAC content #6601

tomislavturcic opened this issue Oct 30, 2019 · 5 comments
Assignees
Labels

Comments

@tomislavturcic
Copy link

tomislavturcic commented Oct 30, 2019

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:

SimpleExoPlayer exoPlayer = ExoPlayerFactory.newSimpleInstance(context, 
                createRenderersFactory(context), 
                new DefaultTrackSelector());
DataSource.Factory dataSourceFactory = new DefaultDataSourceFactory(context, Util.getUserAgent(context, "ExoPlayerTest"));

Creating RenderersFactory instance. (I've tried various options here, all lead to same results).

private RenderersFactory createRenderersFactory(Context context) {
        DefaultRenderersFactory factory = new DefaultRenderersFactory(context);
        factory.setExtensionRendererMode(DefaultRenderersFactory.EXTENSION_RENDERER_MODE_PREFER);
        return factory;
}

Creating MediaSources for ConcatenatingMediaSource:

private MediaSource createMediaSource(PlayerTrack track) {
        return new ProgressiveMediaSource.Factory(dataSourceFactory)
                .setTag(track)
                .createMediaSource(Uri.parse(track.url));
}

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 dev.exoplayer@gmail.com.

@tomislavturcic tomislavturcic changed the title LibflacAudioRenderer not being used for FLAC content Noise when playing FLAC content Oct 31, 2019
@herintsoaRazaf
Copy link

I'm facing the same issue after an update of Exoplayer to 2.10.5 version.

@andrewlewis andrewlewis self-assigned this Oct 31, 2019
@andrewlewis
Copy link
Collaborator

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?

I think this part is working as intended assuming you are playing audio in a .flac container file. FlacExtractor outputs PCM because of the way the file is structured. (LibflacAudioRenderer is needed for decoding FLAC without using a platform decoder where the audio comes from another container like Matroska.)

I am also unable to build FLAC libs on 2.10.6 version.

Looks like we need to switch to NDK 20, which also requires using c++_static not gnustl_static. I will make the fix.

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 ?

Still investigating this.

ojw28 pushed a commit that referenced this issue Nov 5, 2019
- 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
@kgrevehagen
Copy link

kgrevehagen commented Nov 13, 2019

Look at this comment in #6608 for a potential cause and fix for the one you are still investigating.

@andrewlewis
Copy link
Collaborator

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).

ojw28 pushed a commit that referenced this issue Nov 22, 2019
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
ojw28 pushed a commit that referenced this issue Nov 22, 2019
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
ojw28 pushed a commit that referenced this issue Nov 27, 2019
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
ojw28 pushed a commit that referenced this issue Nov 27, 2019
Issue: #6601
PiperOrigin-RevId: 282515179
ojw28 pushed a commit that referenced this issue Nov 27, 2019
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
ojw28 pushed a commit that referenced this issue Nov 27, 2019
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
ojw28 pushed a commit that referenced this issue Nov 27, 2019
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
ojw28 pushed a commit that referenced this issue Nov 27, 2019
Issue: #6601
PiperOrigin-RevId: 282515179
ojw28 pushed a commit that referenced this issue Nov 27, 2019
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
ojw28 pushed a commit that referenced this issue Nov 27, 2019
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
@ojw28
Copy link
Contributor

ojw28 commented Nov 27, 2019

This should be fixed in the dev-v2 and dev-v2-r2.11.0 branches.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

5 participants