mmitch / gbsplay

gameboy sound player

Home Page:https://mmitch.github.io/gbsplay/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Text output differences when using ALSA vs. PulseAudio

ruby-R53 opened this issue · comments

I just realized that when using ALSA, I get a different output compared to PulseAudio, also including how gbsplay reacts to input.

Starting with input, when I use PulseAudio, there's a small delay between when I press a key and the program responds, while on ALSA, gbsplay responds immediately to my keypress. I'm guessing it has to do with the -R option, but why does Pulse follows it while ALSA doesn't?

And as for the text output, when I unpause a tune using the ALSA driver, gbsplay prints that info text (that "Song x/y (title)" thing) again instead of updating its line. It gets triggered every time I specifically unpause the tune for some reason, and it can be a bit annoying.

It gets even worse when I have the -v flag. Not only the info text gets repeated when unpausing, but also, the 5th and beyond bytes of the WAVE section get pasted to the previous line, so it turns into a big mess! Using PulseAudio instead of ALSA fixes this, but I wonder why.

As for the messed up terminal output, it's probably logging some error which immediately gets overwritten by the UI. Try running with -qq to get a clear view of what's happening underneath :)

image

ahh, i see it now! that's weird, not sure if that has to do with ALSA itself or gbsplay...

Getting the same error actually, with -o alsa 🤔

ahh, so it's not coming from my system only lol

The commit above should fix the error message on resume for ALSA devices that support pause in hardware.

For devices without pause support there seem to be different methods using snd_pcm_drop() or snd_pcm_rewind() (see https://stackoverflow.com/questions/73056477/pause-alsa-pcm-handle-without-snd-pcm-pause), I'm still looking into that.

https://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2pcm_8c-example.html seems to shed some light on this.
It looks like the EPIPE error points to a simple buffer underrun which is is totally legit when we simply stop writing data to ALSA during pause.

hey, it does fix it indeed!

The commit above should also fix things, but in a different way. I have looked at write_loop() and xrun_recovery() from https://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2pcm_8c-example.html and think we were missing some cases.

Lots of tangled conditions on this one. If the code makes sense to anybody, perhaps it's best to apply this and then add the proper pause handling (where supported™) from e743484 on top.

@mrehkopf fixed the bug in parallel to me, so we could compare our notes :-)
His fix has been merged to master.

@ruby-R53 could you please test it?
Looks good on my side.

it's working perfectly now! nice job!