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

[Thomas Huth <th.huth@xxxxxx>]

Am Sat, 10 Sep 2016 23:34:46 +0200
schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:

> Le 10/09/2016 à 23:00, Thomas Huth a écrit :
> > 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).
> >  
> 
> Yes I'm aware of this ; but my point is that if we call the sound 
> duplication part, then it means the host pc (raspberry or other) is 
> certainly not powerful enough to run Hatari.
> 
> Sound emulation is really less demanding than cpu/video emulation, so
> if we reach the part to duplicate sound, then it certainly means that 
> cpu/video are also lagging far behind and are unable to run at 50 Hz
> for example.
> 
> So overall emulation will already be quite jittered, I don't think 
> trying to fix the audio buffer in that case will improve anything to
> the situation. If video output is not smooth, the user will already
> see that sthg is wrong and outputting 0 byte for sound instead will
> not degrade the situation that much, the situation is already bad ;)

OK, I've now done some quick and certainly non-representative tests by
simply adding a hack a la "nGeneratedSamples = len * 9 / 10" at the
beginning of the callback function, to see whether I could hear a
difference between setting the remaining part of the buffer to 0 or
duplicating the samples. But I have to say that both just sounded bad.
Maybe the sample duplication was a tiny little, little bit better than
the setting to 0, but that could also be just my imagination.

So let's do the "keep it simple" principle here and go for your
suggestion to always set the remaining part of the buffer to 0.

Could you do that "memset-to-zero" patch, or shall I do it?

 Thomas