Re: [hatari-devel] SDL1 vs. SDL2 sound pausing

[Thomas Huth <th.huth@xxxxxx>]

Am Sat, 10 Sep 2016 22:30:55 +0200
schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:

> Le 10/09/2016 à 22:19, David Savinkoff a écrit :
> 
> > I think we should not make big changes because Hatari has worked
> > well for a long time. Note that this problem is an Apple(tm) glitch.
> > I think that adding an improvement to the old code is better than
> > staring over with a new concept.
> >
> >  
> 
> I wouldn't call replacing the sound duplication by some 0 bytes a big 
> change or a new concept, impacts are minimal.
> 
> When Hatari is duplicating sound samples, it means the host pc is not 
> fast enough ; are there really many people today with some PC not
> fast enough to run Hatari in ST/STE mode ?

Some people are running Hatari on the raspberry pi, mobile phone or
other embedded devices that do not have that much CPU power (yet).

> IMO, this sound duplication is confusing from a code-wise logic, and
> it prooved to be wrong as we discovered that it was the cause of the
> sound problem under OSX.

Remember that samples duplication is only done "if (nGeneratedSamples
>= len/2)" - but on OSX, we enter the callback function with
nGeneratedSamples set to 0.
So, no, the problem on OSX is not the samples duplication, it some junk
data in the buffer from the previous sound frame that did not get
erased inbetween.
So maybe something like this would be a good approach instead:

diff -r 89f49df7dfc2 src/audio.c
--- a/src/audio.c	Sat Sep 10 17:58:37 2016 +0200
+++ b/src/audio.c	Sat Sep 10 22:59:04 2016 +0200
@@ -101,6 +101,10 @@
 			int remaining = len - nGeneratedSamples;
 			memcpy(pBuffer, stream+(nGeneratedSamples-remaining)*4, remaining*4);
 		}
+		else
+		{
+			memset(pBuffer, 0, (len - nGeneratedSamples) * 4);
+		}
 		CompleteSndBufIdx += nGeneratedSamples;
 		nGeneratedSamples = 0;
 		
?

 Thomas