search

libsidplayfp / sidplayfp

Console SID/MUS player
GNU General Public License v2.0
38 stars 8 forks source link

Play timer runs way too fast up to 50 seconds #20

Closed pezz closed 7 months ago

pezz commented 1 year ago

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 commented 1 year ago

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 commented 10 months ago

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

AlexKurisu commented 10 months ago

Recompiling the player didn't help

pezz commented 10 months ago

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

Try it again maybe?

pezz commented 10 months ago

Didn't mean to reopen this, apologies.

drfiemost commented 10 months ago

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

AlexKurisu commented 10 months ago

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

That didn't help

drfiemost commented 10 months ago

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

AlexKurisu commented 10 months ago

@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 commented 10 months ago

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 commented 9 months ago

Can you confirm this happens with the ALSA driver?

AlexKurisu commented 9 months ago

Can you confirm this happens with the ALSA driver?

How do I make sidplayfp use ALSA driver?

AlexKurisu commented 9 months ago

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 commented 9 months ago

the issue is still here

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

drfiemost commented 9 months ago

Do you have the same problem with pulseaudio?

AlexKurisu commented 9 months ago

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 commented 9 months ago

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

ruby-R53 commented 9 months ago

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 commented 8 months ago

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 commented 8 months ago

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.