Re: [hatari-devel] Re: Interesting sound problems with Hatari? |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] Re: Interesting sound problems with Hatari?
- From: David Savinkoff <dsavnkff@xxxxxxxxx>
- Date: Sun, 20 Apr 2014 14:50:06 -0600 (MDT)
- Thread-index: 1rE1iHGNYJqr4bjm5SqykVUpxS5IaQ==
- Thread-topic: Interesting sound problems with Hatari?
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.
> >
> >