Sophie

Sophie

distrib > Mageia > 9 > x86_64 > by-pkgid > 03c5a49a4e7c5fca6b7ccb833b8a98e1 > files > 1

schismtracker-git20221020-1.mga9.src.rpm

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
===================================================================
diff -up schismtracker-20221020/schism/audio_playback.c.alsa schismtracker-20221020/schism/audio_playback.c
--- schismtracker-20221020/schism/audio_playback.c.alsa	2022-10-20 17:51:29.000000000 +0200
+++ schismtracker-20221020/schism/audio_playback.c	2022-11-18 09:32:14.524792335 +0100
@@ -1294,15 +1294,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