Re: [hatari-devel] Falcon left-right sound swapper bug?

[Laurent Sallafranque <laurent.sallafranque@xxxxxxx>]

> The thing I find curious into the crossbar sound is that sometimes, 
the sound is nice and sometimes, it sounds crappy (with the same program)..

I've tried to record the hatari sound when it plays clearly and when it 
plays crappy and I gave a look at the sound curves into audacity.

I see something that may help to understand where the problem is :

The nice sound shows a "standard" sound curve (which goes up, down ...)

The crappy sound shows at a regular frequency (every 0,02 seconds in the 
recorded case) some holes into the curve :

   - there are 74 values that seems wrong and then, the curve is OK 
during the next 0,02 s and then 67 values shows hole, ...
   - this affects the left voice and the right voice on the same 
periods of time with exactly the same patern (when there's a hole on the 
left voice, there's the same hole on the right voice)


What do I call a hole :

Instead of having a normal up/down variation, in the 74 or 67 wrond 
datas, I can see that the sound curve value are partially filled with zeros.
Here is a fake example to explain the problem :

The normal sound should be

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 
27 28 29 30 31 32 33 34 35 36 37 38 39 40


The corrupted sound looks like : (the hole begins at value 10)

0 1 2 3 4 5 6 7 8 9 10 0 0 0 0 0 0 0 18 0 0 0 0 0 0 0 0 27 0 0 0 0 0 0 0 
0 36 0 0 0 0 0 0 0 0 45 0 0 0 0 0 ...

The number of zeros is frequently 8 consecutives zeros and sometimes only 7.
The zeros appear on both voice left and voice right at exactly the same 
place.


So, there's something into hatari that sometimes corrupts the sound at a 
regular frequency.



Last points :
- If the music plays nicely, it doesn't decrese in quality. If the music 
starts crappy, it never increase in quality. The state (nice/crappy) 
doesn't evoluate in time.
- If you start 10 times a music (quit the music program and launch it 
again) without rebooting hatari, you can have good or bad quality.

Maybe this will ring a bell to someone.
Laurent



Le 16/04/2014 10:03, Laurent Sallafranque a écrit :
> Hi David,
>
> I don't thing the bug is here :
>
> The aim of this code is to separate the sound into a left and a right 
> part.
>
> The sound in the falcon memory is :
>
> LLRRLLRRLLRRLLRR
>
> LL = 1 8 bits or 1 16 bits value
> RR = 1 8 bits or 1 16 bits value
>
> The result into the 2 buffers will look like this :
>
> Left_buffer   : LLLLLLLLLLLL
> Right_buffer : RRRRRRRRRR
>
>
> So, if I read the 1st value (the left voice one), I put it into the 
> left buffer
> If I read the 2nd value, I put it into the right buffer and I've 
> finished for this sound position --> increment the sound buffers (left 
> and right) to the next data.
>
> If you put the  dac.writePosition = (dac.writePosition + 1) % 
> (DACBUFFER_SIZE);  line after the if, the buffer will look like :
>
> Left_buffer   : LL00LL00LL
> Right_buffer : 00RR00RR00
>
> Anyway, I may misendurstand myself. ;)
>
> The thing I find curious into the crossbar sound is that sometimes, 
> the sound is nice and sometimes, it sounds crappy (with the same 
> program).
> For example, when I launch Racer, the music is sometimes nice to hear 
> and sometimes noisy with cracks...
> I haven't found yet why.
>
> But I think that may be that there's a synchro with a VBL or HBL order 
> missing into the crossbar.
> Actually, when a value into the crossbar changes, I take it into 
> account immedialty (recomputing of the frequency, the 8/16 bits size, 
> ...).
> Maybe there's something missing (a buffer, ...)
>
> Another point, into the crossbar (the hardware component, not the 
> emulated code ), there are 2 little buffers (of 32 bytes if I'm right) 
> for the left and the right tracks.
> These buffers can be emply, full, ... and you can test their state 
> with 0xff893c
>
> /**
>  * Write word to CODEC status register (0xff893c).
>  *     Bit 1 :  Left Channel Overflow (0/1)
>  *     Bit 0 : Right Channel Overflow (0/1)
>  */
> void Crossbar_CodecStatus_WriteWord(void)
> {
>     LOG_TRACE(TRACE_CROSSBAR, "Crossbar : $ff893c (CODEC status) 
> write: 0x%04x\n", IoMem_ReadWord(0xff893c));
> }
>
>
>
> I never implemented these 2 buffers (I'm reading directly the sound 
> data from the atari memory.
> This could increase the sound quality.
> I think Nicolas implemented such buffers into the STE emulation part.
>
> Best regards
>
> Laurent
>
>
>
>
>
>
> Le 16/04/2014 02:58, David Savinkoff a écrit :
> > Hi,
> >
> > I looked at line 1772 of /hatari/src/falcon/crossbar.c and found a
> > possible bug:
> >
> > static void Crossbar_SendDataToDAC(Sint16 value, Uint16 sample_pos)
> > {
> >     Uint16 track = crossbar.track_monitored * 2;
> >
> >     if (sample_pos == track) {
> >         /* Left channel */
> >         dac.buffer_left[dac.writePosition] = value;
> >     }
> >     else if (sample_pos == track + 1) {
> >         /* Right channel */
> >         dac.buffer_right[dac.writePosition] = value;
> > /*Bug*/        dac.writePosition = (dac.writePosition + 1) % 
> > (DACBUFFER_SIZE);
> >     }
> > }
> >
> > Shouldn't the /*Bug*/ line be After the 'if' statement ?
> >
> > Sincerely,
> > David Savinkoff