Re: [hatari-devel] Falcon left-right sound swapper bug? |
[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]
Hi David,I introduced these 0 later in the crossbar code, because sometimes, when the 68030 was crashing, there was an horrible repeating sound in hatari. In the real hardware, when a value is read into the little 32 bytes memory, I think it doesn't exist anymore after, so that's why I introduced these 0.
Removing them doesn't remove the problem. Instead, when there's the problem, we can hear an echo (repeating of the latest 0.5 s or so (0.5 is not an exact value here))
2 things I find stange :- when I try to change #define DACBUFFER_SIZE 2048 by 4096 or more, I have no sound or a really really dirty sound
- I've placed a little test which detects a value !=0 and then count when there are more than 6 consecutive 0 in a sound (and then display it found a case) :
int detect_in = 0; int count_in = 0; // Detect in if (dac_LeftData != 0) detect_in = 1; if (detect_in == 1) { if (dac_LeftData == 0) { count_in ++; if (count_in > 6) { fprintf(stderr, "IN > 6\n"); detect_in = 0; count_in = 0; } } } I've placed this code into Crossbar_GenerateSamples :I've places it at the end to detect if there's a 0 hole in the dac_LeftData and in the MixBuffer[nBufIdx][0] I get some few holes when the sound is OK and a lot of holes when the sound is dirty.
So, the echo when I apply your patch (or the 0 value when not) + this test seems to indicate :
- we're sometimes reading the buffer backward (or too far at once, wich, with the modulo DACBUFFER_SIZE returns before the latest values played)
or- we're sometimes reading the buffer many times at the same place (which would be strange according to the code).
I've given a look at nSamplesToGenerate (in the function parameters). It's always 882 (with good or wrong sound)
I continue to look at this. Laurent Le 16/04/2014 21:12, David Savinkoff a écrit :
----- Laurent Sallafranque wrote:Hi David, I don't think the bug is here : The aim of this code is to separate the sound into a left and a right part.Hi Laurent, Thank you for the explanation. I have been comparing dmaSnd.c with crossbar.c and finding ways to improve crossbar.c I noticed that zeros are being written back to a buffer after the data is read so that a subsequent read would be zero... to avoid introducing a zero order hold filtering effect. However; if this buffer is 'actual' Falcon memory, there is a problem. Please see the enclosed patch. Sincerely, David Savinkoff
Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |