Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Text output differences when using ALSA vs. PulseAudio #127

Closed
ruby-R53 opened this issue Apr 28, 2024 · 9 comments
Closed

Text output differences when using ALSA vs. PulseAudio #127

ruby-R53 opened this issue Apr 28, 2024 · 9 comments
Labels
Milestone

Comments

@ruby-R53
Copy link

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.

@mrehkopf
Copy link
Collaborator

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 :)

@ruby-R53
Copy link
Author

ruby-R53 commented Apr 28, 2024

image

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

@mrehkopf
Copy link
Collaborator

Getting the same error actually, with -o alsa 🤔

@ruby-R53
Copy link
Author

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

@mmitch mmitch added the bug label Apr 29, 2024
@mmitch mmitch added this to the 0.0.98 milestone Apr 29, 2024
mmitch added a commit that referenced this issue Apr 29, 2024
This fixes issue #127 for hardware devices with pause support.

Devices without pause support will still get the EPIPE error
message on resume and lose some samples.
@mmitch
Copy link
Owner

mmitch commented Apr 29, 2024

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.

@ruby-R53
Copy link
Author

hey, it does fix it indeed!

mmitch added a commit that referenced this issue Apr 29, 2024
Getting -EPIPE after pausing is no reason to display an error.  If we
don't write data into the ALSA stream while pausing, we have to expect
a buffer underrun.  Just recover silently from that.

This fixes #127 but we might skip some samples on pause/resume in the
ALSA buffer (not sure about this).
@mmitch
Copy link
Owner

mmitch commented Apr 29, 2024

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.

@mmitch
Copy link
Owner

mmitch commented Apr 30, 2024

@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.

@ruby-R53
Copy link
Author

it's working perfectly now! nice job!

@mmitch mmitch closed this as completed May 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants