You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current interface doesn't provide actual status of offload (whether is enabled on the AudioTrack, not whether it's sleeping). It doesn't allow apps making decisions to keep using offload support after a write error, which may be transient.
Requests:
call a new method AudioOffloadListener.isOffloadedPlayback with the value of AudioTrack.isOffloadedPlayback. This may be true, even when sleepingForOffload is false.
Allow AudioOffloadListener to be involved in the DefaultAudioSink maybeDisableOffload decision, such as trying additional times with offload enabled.
Expose the reason for offload being disabled, such as Audio Init errors, or write errors, or not supported for format.
Proposed solution
Add additional methods to AudioOffloadListener that affect the
Alternatives considered
Expose AudioTrack and additional logging.
The text was updated successfully, but these errors were encountered:
Potentially also, allow an offload only mode DefaultSudioSink.OFFLOAD_MODE_ENABLED_ONLY ?
Similar to #133, there are cases where offload can get disabled (a write error) or other app takes over (TBC?) and we end up playing in SW mode and no way to revert back to offload enabled, until we reconfigure.
I think we agreed I'd put up a speculative CL with just
call a new method AudioOffloadListener.isOffloadedPlayback with the value of AudioTrack.isOffloadedPlayback. This may be true, even when sleepingForOffload is false.
and another one that avoids the disabling retry on a write error.
Speculative as in, no issue if we decide not to proceed.
Offload integration is still experimental for now and doesn't expose all the configuration needed.
The final state will likely have a getter similar to `isOffloadedPlayback. I'll keep this enhancement open to track this.
Error recovery could be made configurable, but it's less important and also not currently done for decoder fallback and similar logic elsewhere. (We only have configurable error handling on the loading side at the moment).
Use case description
The current interface doesn't provide actual status of offload (whether is enabled on the AudioTrack, not whether it's sleeping). It doesn't allow apps making decisions to keep using offload support after a write error, which may be transient.
Requests:
Proposed solution
Add additional methods to AudioOffloadListener that affect the
Alternatives considered
Expose AudioTrack and additional logging.
The text was updated successfully, but these errors were encountered: