Re: [hatari-devel] Sound sync patch to play with |
[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]
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
Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |