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

[David Savinkoff <dsavnkff@xxxxxxxxx>]

On Monday 14 May 2012 14:19, Nicolas Pomarède wrote:
> 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

Hi Nicolas,

Here is a patch that addresses all of your requests.
The Utf-8 stuff was an accidental combination of
find, grep, vim, and the Gnome terminal. ?
Sorry for the late reply; my internet was down since
Sunday.

David

Attachment: hatari.sync.2.diff
Description: Binary data