|Re: [hatari-devel] sound bug
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Just to be sure : shall we invest this problem just before the 1.8 or is
it better not to create regressions (also if it is for a good reason)
for now and wait just after the new release ?
Le 27/06/2014 19:13, David Savinkoff a écrit :
----- Laurent Sallafranque wrote:
I think there are 2 problems here :
- one with the general sound quality of Hatari (which is, from my point
of vue, dependant of the CPU accuracy (because the crossbar code is
related to the cpu time)
- one which is the every 4-5 times crappy sound problem which is not
related to the crossbar code (else, we would not have good quality sound
I think it's more a problem of synchro with SDL or something like that,
but I'pm pretty sure that the problem is not in the crossbar algos
(switching to 11 khz and back to 50 khz sometimes fix the crappy sound
problem, but if you do this and activate "trace crossbar" in the
debugger, you'll notice that there's no crossbar event involved, so no
change in the crossbar structure, but only in the "SDL" part of hatari..
I don't think the solution is in an improvement of the crossbar algos (I
may be wrong of course).
My patch is not intended to change the crossbar algorithm, it is an
attempt to do things from an electrical signal perspective.
The patch should make it easier to find future sound problems because
problems will be manifested at the same magnitude as they happen,
rather than showing up as zeros in the sound data.
Does the Falcon write zeros over the data in it's ring buffer with start
and end pointers that over-run each other? This feature needs to be
disabled so that other problems can be found.