Re: [hatari-devel] Sound sync patch to play with

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

On 14/05/2012 02:13, David Savinkoff wrote:
> On Sunday 13 May 2012 14:13, Nicolas Pomarède wrote:
> > On 13/05/2012 20:37, David Savinkoff wrote:
> > > Hi,
> > >
> > > Here is a patch for synchronizing Hatari to sound.
> > > A check box in in the SDL GUI is provided to
> > > enable or disable synchronization.
> > >
> > > Documentation and comments are in the patch.
> > > Give it a try. It should make things better if
> > > there is a problem, and make little difference
> > > otherwise.
> > >
> > > ps. I'm resending this because I hope to have it in
> > > the upcoming hatari release.
> > >
> > > Thanks,
> > > David
> >
> > Hello, I didn't have time to test this yet. I will try to have a look
> > (but other people opinion is also welcomed).
> >
> > But at the base, I'm not sure I can really test this, I rarely
> > experience such latency problems.
> >
> > If you have this often, couldn't it be due to a not enough powerful cpu
> > or bad audio driver for your specific audio hardware ?
> >
> > Nicolas
>
> Hi Nicolas,
>
> I believe the latency is caused when a sound card does not consume
> the samples as fast as the computer provides them. This causes the
> buffers to eventually fill to the maximum before samples are discarded.
>
> A slow cpu will result in no latency, whereas a fast cpu could cause
> latency. My sound card is slower than the computer, and your sound
> card is faster (no sound card is the same speed as the computer).
>
> The fundamental problem is that the sound card's timing is independent
> from the other timers. SDL_GetTicks is flawed in that it uses the PIT timer.
> It should use vsync for the video time-base, and the SDL_audio_callback
> for the sound time-base.
>
> The patch addresses the fundamental problem by using the SDL audio
> callback to smoothly micro-throttle Hatari. Jitter caused by Multitasking
> in Linux is addressed by the sound buffer.
>
> I tested this patch with:
> hatari --sound-buffer-size 10
> Also 5, 20, 30, 40 and others ( I modified sources to get 5 ).
>
> David


Hello

looking at the patch, I think there could be a problem if a program 
changes the screen's refresh rate ; in that case, Audio_EnableAudio() 
will not be called, so "swallow_size = 5793 / nScreenRefreshRate" will 
not be updated and the value won't be the correct one.

I think the part that computes swallow_size should be done everytime in 
Audio_CallBack if bEnableSoundSync==true, not in Audio_EnableAudio(). 
You could also surround the whole code you added in Audio_CallBack with 
"if ConfigureParams.Sound.bEnableSoundSync==true".
Could you submit another patch that fixes this ?

Also, can you look in audio.c, your patch adds :

+#include "video.h"     /* FIXME: video.h is dependent on screen.h
â~@~XHBL_PALETTE_LINESâ~@~Y */

Some utf8 characters seem to be used around HBL_PALETTE_LINE ; are those 
backquotes ? Could you use ascii compatible characters instead ? (we 
should use utf8 for text strings displayed on screen, but for the actual 
code, I don't think we need it).


Nicolas