Re: [hatari-devel] Re: Interesting sound problems with Hatari?

[Douglas Little <doug694@xxxxxxxxxxxxxx>]

Well I applied the patch, and something interesting did happen.

The gaps moved (for the first time). They are now 246 samples apart.

In fact it's possible these were always present, and superimposed upon the 56-sample periodic zeroes - but regardless they still shouldn't be there.

246 is a very interesting number, because it is the number of samples in a VBL at 12khz.

Thoughts? :-)

D

On 20 April 2014 21:50, David Savinkoff <dsavnkff@xxxxxxxxx> wrote:

Hi,

This is exactly what my patch addresses.

----- Douglas Little <doug694@xxxxxxxxxxxxxx> wrote:
> I think that's probably true - I repeated some tests and found zeroes are
> in the MixBuffer also, providing the whole buffer is dumped in the same way
> as the audio output buffer.
>
> However the zeroes are not arriving from the DMA stream to the
> dac.writePosition (which is what I tested previously, and again now). I
> have dumped all of those and the data looks correct.
>
> What does look a bit strange, is the fact that dac.readPosition and
> dac.writePosition will depend on synchronization, and yet zeroes are being
> stuffed into dac.readPosition here:
>
>             case 2:
>                 /* Crossbar->DAC sound only */
>                 dac_LeftData = dac.buffer_left[dac.readPosition];
>                 dac_RightData = dac.buffer_right[dac.readPosition];
>
> *                dac.buffer_left[dac.readPosition] = 0;
> dac.buffer_right[dac.readPosition] = 0;*
>                 break;
>
> I would say that in general, for a SPSC queue,* the reader should never be
> writing anything*. I haven't checked how this is synchronized but I believe
> your patch affects this code exactly. So I'll try it before I go any deeper
> with this.
>
> D
>
>
> The Falcon sound must have the bug because that section of code
> > works well for the STe. Your computer is not slow.
> >
> >