Play timer runs way too fast up to 50 seconds

[pezz]

Hi there,

Wasn't sure whether to report this against the player or libsidplayfp, chose here (hope that's alright).

I've noticed a problem with the player (lib 2.4.2 and player 2.4.1) when you play a tune the timer counts super fast up to 50 seconds then appears to run normally. This causes tunes to not play to their proper length (tunes under 50 seconds end after about 3 seconds).

I've also tried the alpha lib and player for 2.5.0 and it does the same thing.

Cheers.

[pezz]

Never mind, I reinstalled lib 2.4.2 (from Arch repo) and recompiled the 2.4.1 player and this problem has gone away.

Sorry for the noise.

[AlexKurisu]

Just got the same issue on Arch. Library v. 2.6.0, player v. 2.6.2

[AlexKurisu]

Recompiling the player didn't help

[pezz]

Dunno man, I saw this once and recompiling fixed it.

Try it again maybe?

[pezz]

Didn't mean to reopen this, apologies.

[drfiemost]

Weird, it never occurred to me. What if you pass the -b0 parameter?

[AlexKurisu]

Weird, it never occurred to me. What if you pass the -b0 parameter?

That didn't help

[drfiemost]

Hard to tell without reproducing...
Anyone able to isolate the problem?
Specific compiler/version? Compiler flags?

[AlexKurisu]

@drfiemost
Compiler: GCC 13.2.1, binutils 2.41
CFLAGS: -march=x86-64-v3 -mpclmul -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection
LDFLAGS: -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now

[drfiemost]

Tried recompiling with the same flags, except for -march set to x86-64-v2, with gcc 13.2.0 but no sign of the issue.
Does it happens with any tune? Anything special in sidplayfp.ini or in the command line?
I suggest recompiling with a subset of the flags and see if any of those is causing the problem.

[drfiemost]

Can you confirm this happens with the ALSA driver?

[AlexKurisu]

Can you confirm this happens with the ALSA driver?

How do I make sidplayfp use ALSA driver?

[AlexKurisu]

Did the same thing Gentoo does to disable pulseaudio support (sed -i -e 's:libpulse-simple >= 1.0:dIsAbLe&:' configure), the issue is still here. siplayfp fast-forwards to 01:00 on every song, which leads to songs ending minute earlier than they should be.

[AlexKurisu]

the issue is still here

Oops, did this on release version for some reason. Retrying on version from master

[drfiemost]

Do you have the same problem with pulseaudio?

[AlexKurisu]

Do you have the same problem with pulseaudio?

Nope, problem is gone with pulseaudio (did the sed -i -e 's:alsa >= 1.0:dIsAbLe&:' configure thing). With ALSA the problem is still here.

[AlexKurisu]

Also, looks like sidplayfp prefers ALSA if built with both PulseAudio and ALSA

[ruby-R53]

getting the same issue here, in my case it seems to prefer pulseaudio when it has support for both, so i delete the libpulse section in configure.ac to force ALSA

probably the worst way to do it, but whatever

[drfiemost]

Also, looks like sidplayfp prefers ALSA if built with both PulseAudio and ALSA

That should not happen, pulseaudio have the priority over ALSA, unless the initialization fails for some reason :/

probably the worst way to do it, but whatever

We can add a --disable-pulse option, open a new issue if needed.

Back to the problem, we have determined that it affects the ALSA driver and the effect varies with the sampling rate.
At least we have narrowed it down and have a way to reproduce it. Will dig deeper...

[drfiemost]

Can you please try #32 ? The buffer size is now proportional to the sampling rate. It still eats the first frames playing at 8KHz but it seems a bit better than before.