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

> 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

```
```

```
```

```

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