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

[David Savinkoff <dsavnkff@xxxxxxxxx>]

----- Douglas Little wrote:
> Hi David,
> 
> Thanks for looking at this.
> 
> 
> 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.
> >
> 
> Are you sure this particular problem can/should be solved with
> filtering/interpolating?
> 
> The faulty samples seem to be coming from the 'old' state of the buffer
> from previous writes, and from a position unrelated to the current sample
> position. It appears to be a gap in the extraction of data (skipped sample)
> or a race condition between buffer read/write position.
> 
> Given this, I think it can only be correctly fixed by figuring out what
> sort of race condition or addressing bug is causing it. Trying to hide the
> values will just add complexity and likely produce other side effects on
> certain sounds.
> 
> Here's a snap from the latest output, with the zeroes no longer written to
> the readposition.
> 
> https://dl.dropboxusercontent.com/u/12947585/wav4.png
> 
> As you can see, the bad samples don't correlate at all with the current
> sample position, so filtering them won't help. Masking them (by
> interpolating them from neighbors) might, if their position is always known
> - but it will mean dropping a 'good' sample to do so. It seems to me that
> finding/fixing the buffer addressing fault would result in a better
> solution, with no samples dropped?
> 
> D

We, any one who jumps in, will make this work right. Maybe before the
next version. Anyone's work or comments can make a big difference
because Falcon sound is waiting to be completed. My code will be
peer reviewed.

David Savinkoff