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

Another update on this.

Changing the DMA replay buffer from 256 samples to 1024 produces the same result - zeroes inserted into the audio data every 56 samples.

Changing the sample stepping rate from 1.0 to 2.0 in the software mixer doubles the playback frequency of the tone as it should, but still produces zeroes every 56 samples.

The zeroes are not present in the source data, or in the written DMA pages. I did what I could to record the same data to secondary linear buffers to debug it, and to diff the recording against the original sample. I also inspected the DMA pages themselves.

Having tried to rule out everything of my own, I have to conclude that something is going wrong when Hatari receives this data, or when it passes the final mixed audio to the OS. Bear in mind I have 2 different builds - one Windows native, and one Cygwin, obviously using different libraries and each having their own interesting pros and cons. But they both exhibit this problem.

I tried '--trace crossbar' to see if something could be seen in the data, but this just emits a lot of messages showing which devices are connected (interestingly - it reports 3 output devices when only 1 has actually been configured via crossbar via XBios #$8b). It also reports register writes to the DMA address registers but not data being transferred in the pages. '--trace dmasound' does nothing on Falcon, because the DMA/codec mixing stuff is all done by crossbar.c, and 'dmasound' is only logged by dmaSnd.c, which is STE-only.

The code below configures crossbar in my test.. Only one output device is connected. I don't understand why Hatari thinks all 3 (DSP, DMA, Codec) are connected. It's not related to the main problem I have but it's still strange.

    move.w        #1,-(sp)            ; protocol = handshaking
    move.w        #0,-(sp)            ; prescale = 0 / STE compat.
    move.w        #0,-(sp)            ; srcclk = 25mhz
    move.w        #1<<3,-(sp)         ; dst = DAC
    move.w        #0,-(sp)            ; src = "">    move.w        #$8B,-(sp)
    trap        #14
    lea        12(sp),sp

I haven't had any response on the 56-sample-spaced zeroes so far, so I have to assume nobody else has seen it. Maybe somebody will find the time to *record* audio output from Hatari and see if they can reproduce this?

For reference I'm playing a waveform note 'D4' sampled @ 12294Hz, with Hatari configured at 12khz audio quality + synchronize, capturing the sound being emitted through the system mixer, and comparing with the source sample.

I'll see if I can mod Hatari to show me what's being passed to the OS, to narrow down the point where the zeroes first appear (assuming it's not the OS itself).

On 17 April 2014 22:33, Douglas Little <doug694@xxxxxxxxxxxxxx> wrote:

So I'm still digging into this audio replay noise/glitching problem via Hatari and still haven't found a cause I can tie to my own code.

One of the things I did was change the size of the DMA replay buffer, to see if the glitches changed frequency / spacing. This did not affect the result. Several captures with different sized DMA buffers resulted in the same spacing between glitches.

I also tried a Windows native build (daily build FTP) with my own Cygwin build, in a bid to rule out any stuff specific to SDL libraries etc. Problem is still present.

Played via Hatari at 12khz, captured via Audacity at 44khz and with the spacing measured in samples and rescaled, it amounts to something like 200 samples between each glitch in the capture, or 56 samples in real terms, between each glitch in the source data @ 12khz. This seems quite consistent, although occasional glitches have appeared in-between these regular spacings.

The 'glitch' when examined up close, looks like zeroes placed into the DMA stream at regular intervals. See snap below:

https://dl.dropboxusercontent.com/u/12947585/glitch.png

I can't explain this, and can't see it in the data I'm feeding into the DMA pages. Does anyone have a clue where these zeroes might originate?

D

On 16 April 2014 19:05, Douglas Little <doug694@xxxxxxxxxxxxxx> wrote:

....have scraped a little more information on this one.

I dumped the DMA pages for the sample painted in memory, and performed a binary diff against the original sample data on disk, with the WAV header stripped off.. The data is a perfect match, up to the first loop point (which is about 18k into the sample - quite far). Beyond the loop point the deltas correspond to the original sample at the intended loop point.

So the source data being painted into memory is perfect.

This seems to leave 3 possible points of failure:

1) It is somehow being painted into the wrong place in memory, but not so wrong that it results in more than periodic glitches (this seems very unlikely, especially as the 'glitches' correspond to page swaps)

2) What has been painted into the DMA pages is not what is actually going to the 'codec'
3) What is going to the 'codec' is not what is going to the Windows sound system

I'm leaning towards #2 or more likely #3, which means a problem in Hatari or with the coupling of Hatari to the OS sound API, on Windows at least.

I'll keep digging though, just in case ;)

D

On 16 April 2014 18:34, Douglas Little <doug694@xxxxxxxxxxxxxx> wrote:

So apart from the issues already discussed by Laurent/David, I'm having my own world of pain at the moment with another sound issue, and which *seems* to be limited to Hatari based on what I have been able to try so far.

I am doing my best to narrow this down but it is difficult indeed :) So here is what I can tell you.

1) I'm getting distortion while playing back samples in Hatari while emulating F030. (I've been trying to rule out real HW but I'm having other problems with the machine so haven't managed it quite yet).

2) The distortion seems to be related to double-buffering of the DMA pointers which keep the Codec fed continuously with data (think modplayer here). The distortion seems to have a period which roughly matches the buffer length. I currently use a DMA page size of 246 samples, if that means anything to anyone (12khz @ 50hz period).

3) The values involved in the distortion seem to be random but I am not 100% sure since I'm looking at captures of audio output from the emulator.

4) The distortion does not seem to be present in the memory pages being DMA'd to the Codec - filling a circular buffer with the same data and dumping it out looks *correct* and contiguous.

5) The addressing used to increment through the sample has been fixed at one unit (i.e. a direct 1:1 copy of the sample to the DMA buffers with no skipping/duplication of bytes). I have ruled out the mixer code being faulty also - 3 different variants produce identical results.

6) Recording the individual sample *indexes* to a circular buffer shows the expected pattern of 0,1,2,3... until the loop point, after which it resets to 0 and continues for as long as I let it. No problems there either. Loop point in source sample never varies.

7) I tried decoupling the DMA pages using 8 buffers and reading (codec) / writing (my mixer code) 4 buffers apart to be absolutely sure the DMA'd pages are not being written while in use - no improvement. Not the cause.

Other interesting points:

- A very large noise signature can be obtained by just changing Hatari's 'playback quality'. Setting it to 50khz while playing samples at 12khz via the Falcon's Codec results in... mostly noise and not much signal left (see linked capture below). This might just be due to a lack of filtering but it seems to be really, really bad (!).

- Changing the playback quality does not stop the periodic distortion - it just adds more noise per individual sample event.

I have linked a screengrab of what I get from Hatari in the 2 'quality' modes, playing one looped sample.

https://dl.dropboxusercontent.com/u/12947585/wavefm.png

The top capture is the original sample @ 22khz.

The middle capture is replay within Hatari @ 12khz codec rate, but 50khz Hatari quality (yikes! look at the noise levels!).

The lower capture is the same, but set to 12khz Hatari quality. This is the most interesting one - notice the spikes/glitches at spaced intervals?

I'm still looking into this and doing what I can to isolate possible causes but I'm running out of things to look at in my code. Can anything strange be going on in Hatari which could cause the glitches on each DMA page change? Could it be related to the host OS sound interface, or must it be within the emulation layer or the emulated code?

D