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

[ Thread Index | Date Index | More Archives ]

I removed the lines which write zeroes to the readposition (using the patched version) and the majority of glitches now appear 492 samples apart :-z  although there are a few more closely spaced together, including a few at 246. (Note that 492 = 246*2).

What is different, is that the glitches are no longer zeroes - they are erratic values. This suggests it is picking up stale data instead of the written zeroes, at regular intervals. It's probably picking up fortunate data sometimes, just because it is a nice tidy waveform.

Really, it just looks to me like the synchronization of read/write does not work properly for these objects (adc, dac) probably needs revisited. Hatari Falcon sound won't work properly until this is fixed. I bet its happening on games, demos and stuff too if somebody records the output and looks at it :-)

(I would also suggest that the ringbuffer reader should never be writing anything, for any reason - even if it can be made to work, it is technically a side effect and it will eventually have its day in the sun ;-).

If I get time I might try to figure out exactly whats going wrong with the sync but probably not for at least a week and maybe more, as I have a number of other things needing finished. Perhaps somebody familiar with the code can replicate and make sense of it before then.


On 20 April 2014 22:12, Douglas Little <doug694@xxxxxxxxxxxxxx> wrote:
Here is a grab of the new waveform. Glitch (zero) 246 samples, or 1 VBL apart.


On 20 April 2014 22:08, Douglas Little <doug694@xxxxxxxxxxxxxx> wrote:
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? :-)


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

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.
> >
> >

Mail converted by MHonArc 2.6.19+