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

[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 ;)

> > 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:

I agree that the problem is that Buffer keeps the previous data and they 
will be played in a loop when nGeneratedSamples remains 0, that's why I 
think that a memset in all cases to complete the rest of Buffer if 
needed would be enough.

But to compare this duplicate / null byte approach, maybe first we 
should check if the case where nGeneratedSamples<len is really happening 
that much ?

Are there some cases where everything works fine (smooth video), but 
only sound is not able to keep the pace ?

Nicolas