Re: [hatari-devel] sound bug

[David Savinkoff <dsavnkff@xxxxxxxxx>]

----- Laurent Sallafranque wrote:
> OK, great.
> 
> 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 ?

We should get started despite the release; patches may be applied
after.

> 
> Laurent
> 
> 
> Le 27/06/2014 19:13, David Savinkoff a écrit :
> > ----- Laurent Sallafranque wrote:
> >> Hi,
> >>
> >> 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
> >> sometimes).
> >> 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.
> >
> >
> 
> 
>