|[hatari-devel] Re: Interesting sound problems with Hatari?|
[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]
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:
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:
I'll keep digging though, just in case ;)2) What has been painted into the DMA pages is not what is actually going to the 'codec'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)....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:
3) What is going to the 'codec' is not what is going to the Windows sound systemI'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.
DOn 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.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
|Mail converted by MHonArc 2.6.19+||http://listengine.tuxfamily.org/|