[GH-ISSUE #251] Buggy track switching #180

Open
opened 2026-02-28 14:31:10 +03:00 by kerem · 11 comments
Owner

Originally created by @jforberg on GitHub (Jan 8, 2022).
Original GitHub issue: https://github.com/jpochyla/psst/issues/251

Describe the bug
I noticed a regression in current master (2961c05a) compared to the version I was previously running (105f6cc2).

When switching tracks, the sound flakes out for a moment. This is the case in both versions, but the behaviour in current master is worse IMO.

In 105f6cc2, there is just a pop artefact.
In 2961c05a, it sounds like if the current track is first paused, then played again for a short time, then the next track starts playing.

Please see attached video samples.

To Reproduce
Play one track, then start playing another one.

Expected behavior
Clean switch from one track to the next.

Screenshots
105f6cc2
2961c05a

(The visual artefacts are caused by my screen recorder, not seen in real usage.)

Environment

  • OS: Arch Linux
  • Version: 2022-01-07

Additional context
Please let me know what additional info would be helpful and I can provide it.

Originally created by @jforberg on GitHub (Jan 8, 2022). Original GitHub issue: https://github.com/jpochyla/psst/issues/251 **Describe the bug** I noticed a regression in current master (2961c05a) compared to the version I was previously running (105f6cc2). When switching tracks, the sound flakes out for a moment. This is the case in both versions, but the behaviour in current master is worse IMO. In 105f6cc2, there is just a pop artefact. In 2961c05a, it sounds like if the current track is first paused, then played again for a short time, then the next track starts playing. Please see attached video samples. **To Reproduce** Play one track, then start playing another one. **Expected behavior** Clean switch from one track to the next. **Screenshots** [105f6cc2](https://user-images.githubusercontent.com/1269005/148647497-3e551018-efaf-464e-941f-8b33a6b3f67d.mp4) [2961c05a](https://user-images.githubusercontent.com/1269005/148647500-7d5d57c0-61f3-4d4c-a8f1-093bbf64c21b.mp4) (The visual artefacts are caused by my screen recorder, not seen in real usage.) **Environment** - OS: Arch Linux - Version: 2022-01-07 **Additional context** Please let me know what additional info would be helpful and I can provide it.
Author
Owner

@jpochyla commented on GitHub (Jan 9, 2022):

@jforberg Should be fixed in latest master, can you confirm?

<!-- gh-comment-id:1008306257 --> @jpochyla commented on GitHub (Jan 9, 2022): @jforberg Should be fixed in latest master, can you confirm?
Author
Owner

@jforberg commented on GitHub (Jan 11, 2022):

@jpochyla No, the issue is still there in 8f142a3232 unfortunately

<!-- gh-comment-id:1010227145 --> @jforberg commented on GitHub (Jan 11, 2022): @jpochyla No, the issue is still there in 8f142a3232a706537c8477bff43d2e52309f6b78 unfortunately
Author
Owner

@jacksongoode commented on GitHub (Feb 4, 2022):

I can also confirm this behavior on my system.

<!-- gh-comment-id:1029710444 --> @jacksongoode commented on GitHub (Feb 4, 2022): I can also confirm this behavior on my system.
Author
Owner

@instinctualjealousy commented on GitHub (Aug 28, 2022):

This is still the case.

<!-- gh-comment-id:1229537012 --> @instinctualjealousy commented on GitHub (Aug 28, 2022): This is still the case.
Author
Owner

@oleggtro commented on GitHub (Nov 1, 2022):

Hate to be the "+1" guy, but the problem introduced in 2961c05 still persists

<!-- gh-comment-id:1298384402 --> @oleggtro commented on GitHub (Nov 1, 2022): Hate to be the "+1" guy, but the problem introduced in [`2961c05`](https://github.com/jpochyla/psst/commit/2961c05aec0e20feb76b42b3b9e772f46195afe7) still persists
Author
Owner

@arch-btw commented on GitHub (Dec 4, 2022):

Ah I thought I was going crazy, I have this issue too. I noticed that it's specifically bad when it's a track that's not cached.

<!-- gh-comment-id:1336439598 --> @arch-btw commented on GitHub (Dec 4, 2022): Ah I thought I was going crazy, I have this issue too. I noticed that it's specifically bad when it's a track that's not cached.
Author
Owner

@Insprill commented on GitHub (Dec 17, 2022):

This looks to be caused by AudioSink#resume's StreamMsg to resume arriving before CallbackMsg's PlaySource and Resume messages. This is the order in which things end up being executed:
github.com/jpochyla/psst@d70ed81045/psst-core/src/audio/output/cpal.rs (L118-L120) github.com/jpochyla/psst@d70ed81045/psst-core/src/audio/output/cpal.rs (L127-L130) Start playing audio: github.com/jpochyla/psst@d70ed81045/psst-core/src/audio/output/cpal.rs (L193-L199) Set the audio to be played: github.com/jpochyla/psst@d70ed81045/psst-core/src/audio/output/cpal.rs (L241-L243) github.com/jpochyla/psst@d70ed81045/psst-core/src/audio/output/cpal.rs (L250-L252) Unfortunately, I've looked around a bit and can't see a clear way to fix the issue, but maybe this can point someone in the right direction.

<!-- gh-comment-id:1356316095 --> @Insprill commented on GitHub (Dec 17, 2022): This looks to be caused by `AudioSink#resume`'s StreamMsg to resume arriving before CallbackMsg's PlaySource and Resume messages. This is the order in which things end up being executed: https://github.com/jpochyla/psst/blob/d70ed8104533dc15bc36b989ba8428872c9b578f/psst-core/src/audio/output/cpal.rs#L118-L120 https://github.com/jpochyla/psst/blob/d70ed8104533dc15bc36b989ba8428872c9b578f/psst-core/src/audio/output/cpal.rs#L127-L130 Start playing audio: https://github.com/jpochyla/psst/blob/d70ed8104533dc15bc36b989ba8428872c9b578f/psst-core/src/audio/output/cpal.rs#L193-L199 Set the audio to be played: https://github.com/jpochyla/psst/blob/d70ed8104533dc15bc36b989ba8428872c9b578f/psst-core/src/audio/output/cpal.rs#L241-L243 https://github.com/jpochyla/psst/blob/d70ed8104533dc15bc36b989ba8428872c9b578f/psst-core/src/audio/output/cpal.rs#L250-L252 Unfortunately, I've looked around a bit and can't see a clear way to fix the issue, but maybe this can point someone in the right direction.
Author
Owner

@wjp commented on GitHub (May 18, 2023):

I'm also getting this on Linux with cpal's ALSA backend. While debugging this I tried switching cpal to the Jack backend, and that seems to avoid this issue. (Or possibly make it small enough not be noticable.)

Also, looking at the runtime behaviour of the stream callback on my system, the possible explanation given by @Insprill above doesn't seem to be happening here.

That makes me wonder if it could be due to samples remaining in an alsa or hardware buffer, since cpal doesn't seem to let us specify if it should drop any remaining samples in buffers after resuming from the paused state. See https://github.com/RustAudio/cpal/issues/284 .

<!-- gh-comment-id:1552934613 --> @wjp commented on GitHub (May 18, 2023): I'm also getting this on Linux with cpal's ALSA backend. While debugging this I tried switching cpal to the Jack backend, and that seems to avoid this issue. (Or possibly make it small enough not be noticable.) Also, looking at the runtime behaviour of the stream callback on my system, the possible explanation given by @Insprill above doesn't seem to be happening here. That makes me wonder if it could be due to samples remaining in an alsa or hardware buffer, since cpal doesn't seem to let us specify if it should drop any remaining samples in buffers after resuming from the paused state. See https://github.com/RustAudio/cpal/issues/284 .
Author
Owner

@SO9010 commented on GitHub (Aug 4, 2024):

This is still an issue but for me it's hardly noticeable.

<!-- gh-comment-id:2267505076 --> @SO9010 commented on GitHub (Aug 4, 2024): This is still an issue but for me it's hardly noticeable.
Author
Owner

@oleggtro commented on GitHub (Aug 5, 2024):

I'm currently using psst on macOS (built from 2d9bdcb on 2024-07-30 22:50) and can't notice the issue.

<!-- gh-comment-id:2269411279 --> @oleggtro commented on GitHub (Aug 5, 2024): I'm currently using psst on macOS (built from 2d9bdcb on 2024-07-30 22:50) and can't notice the issue.
Author
Owner

@jacksongoode commented on GitHub (Nov 5, 2024):

I don't think its apparent on macOS, but maybe just Linux and Windows?

<!-- gh-comment-id:2458117169 --> @jacksongoode commented on GitHub (Nov 5, 2024): I don't think its apparent on macOS, but maybe just Linux and Windows?
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/psst#180
No description provided.