|Re: [hatari-devel] Sound sync patch to play with
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
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:
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
ps. I'm resending this because I hope to have it in
the upcoming hatari release.
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 ?
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 ).
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
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
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).