losnoco
Slow Seeking/Pausing
Describe Hello, when seeking, pausing, or, in general, interacting with a song, there's a noticeable delay from when it happens to when the song continues (e.g. 0.5-2 seconds). For me personally, it's very noticeable since I like to scrub through songs via my Touch Bar.
To Reproduce
- Load a song
- Start playing it
- Seek to some position
- See it take a second or longer for the song to continue
Expected behavior Continue the song at the position quickly / nearly instantaneous.
Screenshots N/A
Version information:
- macOS version: 13.2.1 (Ventura)
- Cog version: 2732 (2732-g4131d4ea)
Additional context N/A
I have the same issue, and it gets much worse on bluetooth headphones. Up to 2 seconds of delay on each seek (!).
Sorry for being so rude the other day, I've been feeling really down lately, and made the mistake of taking that out on you and your issue.
If we could get a report of which hardware you two have in common, that would be swell. I need a report of exact Bluetooth devices you're experiencing the issue with.
i have the same or similar issue since a few revisions. when i load the player and press play it sometimes takes up to 10s of seconds until the audio starts. it is as if the filesystem lookup takes ages.
hardware: newest macbook pro, m2. does not depend on the audio output selected (macbook speakers, bluetooth, DAC)
if there is a debug build that i can run with DTrace i can probably do that.
@kode54 It's a whole lot worse for me: when seeking, I hear an interruption in the sound, then the track continues from the same position (not the seek destination!) for a second, then the sound breaks up again, and finally it starts playing from the seek destination. But wait, there's more: if I am in the last 10-15 seconds of the track, seeking doesn't work at all.
@kode54 Net improvement! What remains suboptimal (but I can cope) is:
- If I am near the end of the track (say 5 seconds from the end) and I seek all the way back to the beginning, it just stops.
- Seeking is now nice and fast, but very noisy (the typical fart-like sound of corrupted digital audio) which is something I have not experienced in a digital audio system in 25 years - hence my surprise.
Anyhow thanks for this and keep up the good work!
The only way to stop the glitching on seeking is to completely stop and restart playback on every seek operation. Same goes for near end of track seeking, which is working for me already, by already doing this stopping and restarting thing.
Right, any reason why you're not doing that? 🙂
I admit I have never worked on this kind of stuff before, but I am a dev and if you want I can study the problem in detail and work on a PR for you.
It's definitely solvable, I didn't use to have any glitches seeking MP3s with Winamp on a Celeron 500 with 64MB RAM.
Tell me if I can help in any way.
I am now. Wait for version 3008 or possibly newer if I find something else to fix before you update.
Anyone here still waiting? It should be significantly better now. Especially for MP3 files. Can't guarantee, though.
I tried 3170 and the toolbar items seem to seek and pause without, but the interface can hang at times. For example, pausing playback is instant, but the UI will hang for some milliseconds.
At the same time, seeking and pausing from the Touch Bar causes the app to hang indefinitely.
But I don't explicitly support the Touch Bar? I don't know how Touch Bar even interacts with it. I can only use the Touch Bar simulator.
It shows up in the Touch Bar via MPNowPlayingInfoCenter, so I assumed it was supported. The previous, pause/play, and next buttons work, but not the scrubber, which is what hangs. I'm not aware of a method to disable Touch Bar support that wouldn't impact other interfaces like the Now Playing menu bar item (whose slider does work, so maybe the scrubber is sending many events, causing the app to hang).
This should already be somewhat fixed, depending on the formats being played. More DSP fixes are pending, however.