[hatari-devel] STE sound breakage with lower sound frequencies

[David Savinkoff]

On Feb 8, 2011, Eero Tamminen <oak at helsinkinet.fi> wrote: 
> Hi,
> On tiistai 08 helmikuu 2011, Nicolas Pomarède wrote:
> > Le 07/02/2011 23:15, Eero Tamminen a écrit :
> > > I tried Utopos demo.
> > > 
> > > If I use "--sound 11025" or "--sound 16000", there's just a short
> > > "dup"[1] sound and then no sound at all.  With e.g. 22kHz or 48kHz,
> > > sound works fine for STE emulation too.
> > > 
> > > The issue happens also for Hatari from end of december and for Hatari
> > > v1.4. Keyclick on STE TOS works for Hatari v1.4 even at 11025Hz
> > > though.
> > 
> > Yes, I can reproduce similar issues ; not related to my latest changes,
> > certainly there since a long time and specific to dma sound.
> > 
> > It seems that if Hatari starts with a too low freq then there's no sound
> > (changing sound freq with F12 don't correct it). But if I start Hatari
> > in default mode (44.1 kHz) in my case and change freq with F12 to 11025,
> > I still get sound.
> Do you have the same behaviour ?
>
> Yes.  If I change the freq from options, there's no problem.
>
>
> > So, it's not the freq change, but probably some inits based on the
> > starting sound freq that are not correct.
> > 
> > I'll try to give it a look later.
>
> Hm. Does anybody know a good Falcon program to test for the same issue?
>
>
> > > Well, the possible issue is quite theoretical, but can happen also not
> > > just by explicit user time change, but e.g. by automatic switch
> > > to/from daylight savings or due to NTP update.  NTP time corrections
> > > are typically so small (say few secs) that Hatari wouldn't freeze for
> > > very long time though. :-)
> > 
> > ntp corrections should even be smaller than that. Except for a "brutal"
> > ntpdate that can be started when computer boots, changes made by ntp are
> > made with much smaller resolution than milli sec to avoid disturbing all
> > processes ; as for daylight saving, it should affect representation of
> > time relative to your timezone, but not the global time counted in
> > seconds since 1/1/1970.
>
> OK, so only user's own time modifications would be an issue and in this
> very unlike case user can probably "connect the dots" and understand
> why it happened.  :-)

All of this ntp and time changes are dirty enough to force a re-think.
Maybe we should use SDL exclusively as it is cleaner and will 'not' be
less accurate averaged over time. Furthermore main.c would not depend
on #include <time.h>

SDL at 10ms is just as accurate as usleep in microseconds; it is the
precision that is 10ms. To time-average 60Hz VBLs, one only needs to
have a 10ms delay 1/3 of the time and a 20ms delay 2/3 of the time.
eg.
VBL(1) = 10ms
VBL(2) = 20ms
VBL(3) = 20ms
Time average the above over 3 VBLs and you have 16.66... ms
This time averaging has been taking place since Thomas added the code.
In light of this, SDL at 1ms is a luxury.
I don't believe your eyes will bothered, especially if xorg
(or equivalent) is doing its job (buffering). Video is the
only thing that is affected, sound is not.

Sincerely,
David