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

[David Savinkoff <dsavnkff@xxxxxxxxx>]

Hi Douglas,

Thank you for the feedback. I'll improve the patch and add anti-aliasing
over the next few days. I will remove the zeros from the patch and
replace with filtered samples. Note that Hatari has to convert samples
of one sample rate to another in some places.

Also, the microphone needs another ring buffer.

David Savinkoff

----- Douglas Little <doug694@xxxxxxxxxxxxxx> wrote:
> 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.
> 
> D
> 
> 
> 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.
> >
> > https://dl.dropboxusercontent.com/u/12947585/wav3.png
> >
> > D.
> >
> >
> >
> > 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? :-)
> >>
> >> 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.
> >>> > >
> >>> > >
> >>>
> >>>
> >>>
> >>>
> >>
> >