[Scummvm-git-logs] scummvm master -> 9ed3d0b5feb12a5584a69340cb258897c2473052

[mikrosk]

This automated email contains information about 1 new commit which have been
pushed to the 'scummvm' repo located at https://github.com/scummvm/scummvm .

Summary:
9ed3d0b5fe BACKENDS: ATARI: Avoid depletion of mixer slots


Commit: 9ed3d0b5feb12a5584a69340cb258897c2473052
    https://github.com/scummvm/scummvm/commit/9ed3d0b5feb12a5584a69340cb258897c2473052
Author: Miro Kropacek (miro.kropacek at gmail.com)
Date: 2023-04-07T17:31:40+02:00

Commit Message:
BACKENDS: ATARI: Avoid depletion of mixer slots

This was a bad idea from the beginning (see https://github.com/scummvm/scummvm/pull/4687/files#r1096804842)
but fortunately there is an easy and safe workaround: providing a buffer
with zero length. That way mixCallback() is always called while mixing
is avoided.

Also rename "output_samples" to "audio_buffer_size" to be on par with
the official documentation: https://docs.scummvm.org/en/latest/advanced_topics/understand_audio.html#buffer.

Changed paths:
    backends/mixer/atari/atari-mixer.cpp
    backends/platform/atari/readme.txt


diff --git a/backends/mixer/atari/atari-mixer.cpp b/backends/mixer/atari/atari-mixer.cpp
index b4121897ee2..54074f652bb 100644
--- a/backends/mixer/atari/atari-mixer.cpp
+++ b/backends/mixer/atari/atari-mixer.cpp
@@ -80,13 +80,13 @@ AtariMixerManager::AtariMixerManager() : MixerManager() {
 	while (_samples * 16 > _outputRate * 2)
 		_samples >>= 1;
 
-	ConfMan.registerDefault("output_samples", (int)_samples);
+	ConfMan.registerDefault("audio_buffer_size", (int)_samples);
 
-	int samples = ConfMan.getInt("output_samples");
+	int samples = ConfMan.getInt("audio_buffer_size");
 	if (samples > 0)
 		_samples = samples;
 
-	ConfMan.setInt("output_samples", (int)_samples);
+	ConfMan.setInt("audio_buffer_size", (int)_samples);
 	debug("sample buffer size: %d", _samples);
 
 	ConfMan.flushToDisk();
@@ -183,7 +183,7 @@ bool AtariMixerManager::notifyEvent(const Common::Event &event) {
 }
 
 void AtariMixerManager::update() {
-	if (_audioSuspended && !_muted) {
+	if (_audioSuspended) {
 		return;
 	}
 
@@ -211,7 +211,7 @@ void AtariMixerManager::update() {
 	if (_atariInitialized && buf != nullptr) {
 		assert(_mixer);
 		// generates stereo 16-bit samples
-		int processed = _mixer->mixCallback(_samplesBuf, _samples * 4);
+		int processed = _mixer->mixCallback(_samplesBuf, _muted ? 0 : _samples * 4);
 		if (processed > 0) {
 			memcpy(buf, _samplesBuf, processed * 4);
 		} else {
diff --git a/backends/platform/atari/readme.txt b/backends/platform/atari/readme.txt
index 011df70f900..fcc173bfcd8 100644
--- a/backends/platform/atari/readme.txt
+++ b/backends/platform/atari/readme.txt
@@ -84,13 +84,13 @@ toggle.
 24585, 19668, 16390, 12292, 9834, 8195 (the lower the value, the faster the
 mixing but also in worse quality). Default is 24585 Hz (16-bit, stereo).
 
-"output_samples" in scummvm.ini: number of samples to preload. Default is 2048
-which equals to about 83ms of audio lag and seems to be about right for most
-games on my CT60 at 66 MHz.
+"audio_buffer_size" in scummvm.ini: number of samples to preload. Default is
+2048 which equals to about 83ms of audio lag and seems to be about right for
+most games on my CT60 at 66 MHz.
 
 If you want to play with those two values, the rule of thumb is: (lag in ms) =
-(output_samples / output_rate) * 1000. But it's totally OK just to double the
-samples value to get rid of stuttering in a heavier game.
+(audio_buffer_size / output_rate) * 1000. But it's totally OK just to double
+the samples value to get rid of stuttering in a heavier game.
 
 
 Graphics modes
@@ -287,11 +287,12 @@ CD music slows everything down
 Some games use separate audio *and* video streams (files). Even if the CPU is
 able to handle both, the bottleneck becomes ... disk access. This is visible in
 The Curse Of Monkey Island for example -- there's audible stuttering during the
-intro sequence (and during the game as well). Increasing "output_samples" makes
-the rendering literally crawling! Why? Because disk I/O is busy with loading
-even *more* sample data so there's less time for video loading and rendering.
-Try to put "musdisk1.bun" and "musdisk2.bun" into a ramdisk (i.e. u:/ram in
-FreeMiNT), you'll be pleasantly surprised with the performance boost gained.
+intro sequence (and during the game as well). Increasing "audio_buffer_size"
+makes the rendering literally crawling! Why? Because disk I/O is busy with
+loading even *more* sample data so there's less time for video loading and
+rendering. Try to put "musdisk1.bun" and "musdisk2.bun" into a ramdisk (i.e.
+u:/ram in FreeMiNT), you'll be pleasantly surprised with the performance boost
+gained.
 
 "Mute" vs. "Mute all" in GUI vs. "No music" in GUI
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -364,8 +365,8 @@ Future plans
 
 - avoid loading music/speech files (and thus slowing down everything) if muted
 
-- cached audio/video streams (i.e. don't load only "output_samples" number of
-  samples but cache, say, 1 second so disk i/o wont be so stressed)
+- cached audio/video streams (i.e. don't load only "audio_buffer_size" number
+  of samples but cache, say, 1 second so disk i/o wont be so stressed)
 
 - using LDG or Thorsten Otto's sharedlibs: https://tho-otto.de/sharedlibs.php
   for game engine plugins to relieve the huge binary size