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

[Laurent Sallafranque <laurent.sallafranque@xxxxxxx>]

Hi,

I've patched hatari to enable the zeroing of the dac only when n > 0 (as Doug suggested) and I'm zeroing all the values between the current position and the next one (if n > 1).

Doug and David, can you tell me if everything seems OK to you in this little patch ?

David, I'll add your FIFO patch later, because I didn't noticed any change in the sound problem when I applied it and I'd like to understand where the problem comes from before applying patches.

Something I noticed tonight : when I launch racer (current developping release ;)  and I get the noisy music, I press F12 to go to hatari GUI, then I change the sound to another frequency and the noise seems to disapear (I get a clean music). If I return to the original frequency (50 khz for my settings), the sound stays clean.

This may mean that the problem is not into the crossbar emulation (as I just press F12 (hatari gui) and return to emulation, there's no crossbar settings involved here), but it may comes from a SDL sound synchro problem ?

Anybody can confirm that ?

Regards

Laurent



Le 01/05/2014 10:26, Douglas Little a écrit :

Hi,

I need clarification on what works.
Is fifo-mic.1.patch satisfactory?
What needs improvement?

Unfortunately I am unable to test that patch in any meaningful way - I am only working with specific circumstances for audio replay on Falcon, which is critical to completing my own project.

 

----- Douglas Little wrote:
> I think the changes I proposed shouldn't be considered final - there is

what changes in particular?

The changes discussed earlier in this thread, relating to the storing of zeroes to the Codec ringbuffer read head. Zeroes are pushed on the first access to the current read position, but the read position is not assured to move forward by one whole unit (fixedpoint increment). So the next fetch can become corrupted with unexpected zeroes.

 

> probably a more correct way to fix it. However, I had a bad experience this
> evening which suggests something really should be done soon - either apply
> the temporary fix with intent to figure out a better solution, or fix it

which fix is this?

As referenced above - the zeroes are stored to the read head only if the ringbuffer read head actually advances for that sample.

I offered opinions that storing to the read head at all might not be a good idea - and LaurentS also suggested that the read head could move forward by more than one unit, dependent on replay frequency etc. Which I also agree with. So I believe a more conclusive fix is waiting to be developed. I'm just not in a good position to figure out the right way, partly due to time and partly because I don't have a good enough understanding of the purpose of these writes, except that they fix some other problem.
 

> Of course only at this point I realized I had been running the 'wrong'
> version of Hatari out of habit (the downloaded version via shortcut,
> instead of my local build which includes the patch, launched via CygwinX)

which patch?

I didn't actually submit a diff/patch file - I just highlighted the code in the message, and which corrections i made. It can be found a few messages back, under the same topic header.

If a literal patch file is needed I can supply one, but the change is trivial - moved a couple of lines, added an if statement .

D.