yonlu/yellowjacket
1
1
Fork 0
Code Issues 55 Pull Requests 6 Actions Packages Projects Releases 12 Wiki Activity

Android: some songs play back sped up #227

New Issue
Open
opened 2026-08-27 00:04:47 +00:00 by logan · 0 comments
logan commented 2026-08-27 00:04:47 +00:00
Collaborator
Copy Link
Copy Source

Report

On Android, some songs play back sped up (higher pitch, shorter
than their real duration). Not every track — most play correctly — and
it has not yet been pinned to a format, a sample rate or a particular
route into playback. Reported from listening on the device, not
measured.

What this is not

  • Not #124, which is fixed and has a regression test
    (backend/player/loadstate_test.go): p.format is assigned in
    loadFileLocked now, so the replay-after-finish path no longer
    declares a 48 kHz decoder to be 44100. Worth re-checking that the
    reported tracks are not all replays of a finished track, since that
    is the exact symptom that bug produced and the closest known
    precedent.
  • Not obviously #194 either, though it is the neighbouring fact:
    the speaker is opened at a hard-coded 44100
    (backend/player/player.go:168) while the device's output stream
    runs at 48000. A stream handed to the platform at the wrong rate and
    played out without resampling is 44100/48000 — 8.8% fast, which
    is roughly the size of the effect described. That would be every
    track though, so if the ratio matches, the question becomes what
    makes it intermittent (a route where Oboe opens a different stream —
    the device was observed taking the OpenSL ES path rather than AAudio).

Where to look

  • backend/player/player.go — updateStreamers takes the decoder's
    rate and resamples to speakerSampleRate; anything that reaches it
    with a wrong sr plays at the wrong speed and the position
    arithmetic goes with it.
  • p.format is now set on load, but the seek and auto-advance paths
    should be checked for the same assumption #124 was made of.
  • Whether the sped-up tracks share a sample rate (48 kHz vs 44.1 kHz)
    or a container (FLAC/OGG/MP3/WAV) is the first thing to establish —
    the ratio names the fault.

To reproduce / what is needed

  1. Which tracks: file, container, sample rate (ffprobe or the app's
    own track details).
  2. Whether it happens on first play or only after the track has
    finished once.
  3. Rough size of the effect — a 3:00 track finishing at ~2:45 is the
    44100/48000 ratio; a track at double speed is a channel-count
    fault instead.
  4. dumpsys audio for our pid while a sped-up track is playing, for
    the FormatInfo{...sampleRate=} line — same measurement #194
    carries.
**Report** On Android, **some** songs play back sped up (higher pitch, shorter than their real duration). Not every track — most play correctly — and it has not yet been pinned to a format, a sample rate or a particular route into playback. Reported from listening on the device, not measured. **What this is not** - **Not #124**, which is fixed and has a regression test (`backend/player/loadstate_test.go`): `p.format` is assigned in `loadFileLocked` now, so the replay-after-finish path no longer declares a 48 kHz decoder to be 44100. Worth re-checking that the reported tracks are not all *replays of a finished track*, since that is the exact symptom that bug produced and the closest known precedent. - **Not obviously #194** either, though it is the neighbouring fact: the speaker is opened at a hard-coded 44100 (`backend/player/player.go:168`) while the device's output stream runs at 48000. A stream handed to the platform at the wrong rate and played out without resampling is 44100/48000 — **8.8% fast**, which is roughly the size of the effect described. That would be *every* track though, so if the ratio matches, the question becomes what makes it intermittent (a route where Oboe opens a different stream — the device was observed taking the OpenSL ES path rather than AAudio). **Where to look** - `backend/player/player.go` — `updateStreamers` takes the decoder's rate and resamples to `speakerSampleRate`; anything that reaches it with a wrong `sr` plays at the wrong speed and the position arithmetic goes with it. - `p.format` is now set on load, but the seek and auto-advance paths should be checked for the same assumption #124 was made of. - Whether the sped-up tracks share a sample rate (48 kHz vs 44.1 kHz) or a container (FLAC/OGG/MP3/WAV) is the first thing to establish — the ratio names the fault. **To reproduce / what is needed** 1. Which tracks: file, container, sample rate (`ffprobe` or the app's own track details). 2. Whether it happens on first play or only after the track has finished once. 3. Rough size of the effect — a 3:00 track finishing at ~2:45 is the 44100/48000 ratio; a track at double speed is a channel-count fault instead. 4. `dumpsys audio` for our pid while a sped-up track is playing, for the `FormatInfo{...sampleRate=}` line — same measurement #194 carries.
logan added the Area/Player
Priority
High
2
Kind/BugPlatform/Android labels 2026-08-27 00:04:48 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Area/Design
Area/Downloads
Area/Explore
Area/Library-UI
Area/Metadata
Area/Packaging
Area/Player
Area/Queue
Area/Settings
Area/Shell-Nav
Compat/Breaking
Breaking change that won't be backward compatible
 Kind/Bug
Something is not working
 Kind/Documentation
Documentation changes
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New functionality
 Kind/Security
This is security issue
 Kind/Testing
Issue or pull request related to testing
 Platform/Android
Platform/Desktop
Priority
Critical
1
The priority is critical
Priority
High
2
The priority is high
Priority
Medium
3
The priority is medium
Priority
Low
4
The priority is low
Reviewed
Confirmed
1
Issue has been confirmed
Reviewed
Duplicate
2
This issue or pull request already exists
Reviewed
Invalid
3
Invalid issue
Reviewed
Won't Fix
3
This issue won't be fixed
Status
Blocked
1
Something is blocking this issue or pull request
Status
Need More Info
2
Feedback is required to reproduce issue or to continue work
Status
Abandoned
3
Somebody has started to work on this but abandoned work
Status
In Progress
Somebody is actively working on this right now
No labels Area/Player Kind/Bug Platform/Android
Priority
High
2
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
logan yonlu
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: yonlu/yellowjacket#227