forked from pool/schismtracker
Jan Engelhardt
04d62c2ac5
OBS-URL: https://build.opensuse.org/package/show/multimedia:apps/schismtracker?expand=0&rev=46
62 lines
2.7 KiB
Diff
62 lines
2.7 KiB
Diff
From: Jan Engelhardt <jengelh@medozas.de>
|
|
|
|
schism/audio: do not force "hw" ALSA device
|
|
|
|
Forcing direct hardware access using the "hw" device is incorrect
|
|
IMHO, especially so with sound chips that lack hardware mixing on any
|
|
of the three levels: (1) concurrent access to the hw device, (2) lack
|
|
of volume control, (3) lack of rate conversion.
|
|
|
|
"default" is the better choice to have schism output to the converters
|
|
that handle any or all of these three points.
|
|
|
|
Developer Storlek claims problems with fake devices. Upon furhter
|
|
investigation, fake devices such as the ALSA plugins have a reason to
|
|
ignore it, or at least tinker with it. Consider my case with a
|
|
Realtek ALC259 (driven by snd-hda-intel) that fails (1) and (3):
|
|
|
|
By default, schismtracker asks for 1024 fragments and 44.1 kHz. If
|
|
the sound chip however does not support hardware mixing and can only
|
|
do, for example, 48 kHz, ALSA will automatically add converters into
|
|
the audio chain such that the program can still operate at 44100 Hz
|
|
without distorted sound.
|
|
|
|
1024 fragments of 128 bytes each are requested and thusly allocated,
|
|
that is, the sound buffer will be 128 kilobytes in total. This value
|
|
is taken at face - but for 48 kHz. The 44.1 kHz ALSA user thus only
|
|
gets a 44100/48000*131072 = 120422 byte buffer, or 940 fragments. The
|
|
rate conversion will then automatically interpolate the signal to
|
|
1024 fragments. (No distortions or lag ensues from this for me.)
|
|
|
|
So 940 is correct and the comment seemingly bogus.
|
|
|
|
Storlek still does not like changing "hw" :-(
|
|
|
|
A workaround is to call schismtracker with the "-a alsa:default"
|
|
option.
|
|
---
|
|
schism/audio_playback.c | 7 +------
|
|
1 file changed, 1 insertion(+), 6 deletions(-)
|
|
|
|
Index: schismtracker-20220807/schism/audio_playback.c
|
|
===================================================================
|
|
--- schismtracker-20220807.orig/schism/audio_playback.c
|
|
+++ schismtracker-20220807/schism/audio_playback.c
|
|
@@ -1295,15 +1295,10 @@ static int _audio_open(const char *drive
|
|
if (SDL_InitSubSystem(SDL_INIT_AUDIO) < 0)
|
|
return 0;
|
|
|
|
- /* This is needed in order to coax alsa into actually respecting the buffer size, since it's evidently
|
|
- ignored entirely for "fake" devices such as "default" -- which SDL happens to use if no device name
|
|
- is set. (see SDL_alsa_audio.c: http://tinyurl.com/ybf398f)
|
|
- If hw doesn't exist, so be it -- let this fail, we'll fall back to the dummy device, and the
|
|
- user can pick a more reasonable device later. */
|
|
if ((driver_name = SDL_GetCurrentAudioDriver()) != NULL && !strcmp(driver_name, "alsa")) {
|
|
char *dev = getenv("AUDIODEV");
|
|
if (!dev || !*dev)
|
|
- put_env_var("AUDIODEV", "hw");
|
|
+ put_env_var("AUDIODEV", "default");
|
|
}
|
|
|
|
/* ... THIS is needed because, if the buffer size isn't a power of two, the dsp driver will punt since
|