|Re: [hatari-devel] Sound sync patch to play with|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On 19/05/2012 05:26, David Savinkoff wrote:
On Tuesday 15 May 2012 13:41, Eero Tamminen wrote:
On maanantai 14 toukokuu 2012, David Savinkoff wrote:
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).
Isn't Hatari sound sample speed controlled by the selected sound frequency?
It may be possible to make the sound card to use the 44100 Hz sample rate,
while throttling YM2149 sampling with 44000 to 44200 Hz in a control loop.
I.e. isn't this a user error of selecting higher output HZ from Hatari
options than what the sound card supports? And shouldn't Hatari audio
part reject / correct such a choice?
The problem is that the sound FIFO is not controlled at a given level,
therefore drifts to either overflowing or underflowing. The host
computer puts samples into the FIFO at what it believes to be
approximately 44100 Hz, and the sound card takes samples from
the FIFO at what it believes to be approximately 44100 Hz, where
Host sample rate != Sound card sample rate, and both are subject
to independent frequency variations (temperature, age, tolerance).
I agree on this 2 different clocks (cpu and sound card), but then I
would assume this is the work of the audio callback function to trigger
when the current sound buffer is played.
If a PC has such drift and the audio driver is correct, then I think the
OS audio callback should be able to request sample a little sooner or a
little earlier, which should have the same effect as your patch. Your
patch adjust the video part to match the audio, a proper audio driver
(which is the bridge between the audio hardware and the cpu) should IMO
detect this itself by changing slightly the audio callback frequency.
Also, even if clocks are different between cpu and audio, we're just
talking about 44.1 kHz most of the time, I'm rather surprised some sound
hardwares are not able to keep this frequency with a unnoticable
precision (especially since most sound cards are wired on the
motherboard, so getting a proper clock common with the cpu should be
No "offence" to your PC, but maybe you're using a crappy sound card or
the audio driver was not correctly coded ?
Still, as your patch is not too intrusive and can be disabled, I will
add it ; I'm quite skeptical it will be of use to lots of people, but
who knows :)