[hatari-devel] Slow sound buffer

[David Savinkoff]

> On Jan 18, 2011, Nicolas Pomarède <npomarede at corp.free.fr> wrote: 
>
> Le 18/01/2011 06:39, David Savinkoff a écrit :
>> Hi,
>>
>> I found that making the timer delays more accurate helps with
>> sound synchronization. In Main_WaitOnVbl(void) of main.c
>> for example: nFrameDuration = 1000/nScreenRefreshRate
>> results in 16 milliseconds when nScreenRefreshRate is 60Hz
>> but it should be 16.66... This is a 100%*(16.66-16)/16 = 4.17%
>> syncronization mismatch at 60 Hz. Solved, but CPU ticks are
>> Not sound system sample rates (separate hardware with separate
>> crystals). Thus hatari Must do more, and that is done in sound.c
>>
>> //fprintf ( stderr, "%d\n", nGeneratedSamples-len); was put in
>> audio.c to display excess samples count for experimenting.
>>
>> Problem solved and the sound is perfect!
>>
>> Sincerely,
>> David
>>
>
> thanks, I will look at this later (I'm a little busy these days) and 
> will try to commit some changes for video freq (it's indeed true that 
> 60Hz gives more rounding error than 50 Hz with the various output freq).
>
> From what I see, this improve rounding error for dma sound too, is that
> right ?
>
> Nicolas

Hi,

Main_WaitOnVbl() waits on each emulated VBL to synchronize the real
time with the emulated ST. This now has less rounding error but
probably doesn't make a difference unless it is taken advantage of.

Your question about dma sound raised some issues with:
#define SAMPLES_PER_FRAME  ((nAudioFrequency+35)/nScreenRefreshRate)
Furthermore, I changed it (in sound.c) to:
#define...((nAudioFrequency + d_nAudioFrequency)/nScreenRefreshRate)
I have to use a different variable to do the frequency offset.

It looks like nAudioFrequency+35 is meant to give more samples per
frame at lower sample frequencies, but doing this will mess with
FreqRatio in dmaSnd.c

David