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

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


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




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/