-
Notifications
You must be signed in to change notification settings - Fork 20
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
Comments
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 :) |
Getting the same error actually, with |
ahh, so it's not coming from my system only lol |
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.
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 https://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2pcm_8c-example.html seems to shed some light on this. |
hey, it does fix it indeed! |
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).
The commit above should also fix things, but in a different way. I have looked at 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. |
it's working perfectly now! nice job! |
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 theWAVE
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.The text was updated successfully, but these errors were encountered: