[hatari-devel] STE sound breakage with lower sound frequencies
Eero Tamminen
oak at helsinkinet.fi
Mon Feb 7 23:15:38 CET 2011
Hi,
On maanantai 07 helmikuu 2011, Nicolas Pomarède wrote:
> Le 06/02/2011 21:43, Eero Tamminen a écrit :
> > This fixed the US TOS issue for ST TOS, but I just noticed a regression
> > for STE TOS. There isn't anymore keyclick sound on STE desktop,
> > just a short sound on first key press and then silence...
>
> That's surprising, I tested with 1.62fr and 1.62us and didn't notice
> your problem ; do you get sound with a demo/game started from tos ?
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.
[1] I hear it also if I open options dialog and then continue emulation.
> If you uncomment line 105-106 in main.c (to use SDL functions), does it
> still happen ?
Doesn't help.
> >> nanosleep() and gettimeofday() are POSIX, so all conforming unixes
> >> should have them (Linux and OSX for example).
> >
> > As only the interval is interesting (not timezone etc corrected
> > wall clock time) why to use gettimeofday() instead of
> > clock_gettime(CLOCK_MONOTONIC,...)?
>
> Because I wanted to have a function that works for OSX too, and
> clock_gettime is not available up to OSX 10.6 at least from what I found
> (it seems Apple didn't implement these posix extensions).
Ok, fair enough. :-)
> clock_gettime gives nanosec when reading it, but as long as we need only
> microsec, it's not necessarily useful for our case.
>
> Well, of course, if someone use settimeoday() while hatari is running,
> this can mess with gettimeofday, but I'm not sure this is a real problem
> ?
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. :-)
- Eero
More information about the hatari-devel
mailing list