[hatari-devel] DMA sound improvements

[Nicolas Pomarède]

Le 10/04/2011 21:43, Laurent Sallafranque a écrit :
> Hi Nicolas,
>
> I was reading about your DMA patch.
>
> I think it would have been better to add a Sound_HBL_Update() function
> in sound.c
>
> In this function, there would be a test like this :
> if falcon
> call crossbar_update_hbl
> else
> call dma_snd_update_hbl.
>
> Like this, I could use the hbl udpate too in crossbar.c

Well, I thought about this, but the fact is that I really don't know how 
the falcon "ste dma emulation mode" works regarding the interaction with 
the video, the bus accesses and the use of an 8 bytes FIFO or not (I 
don't have docs on this, but my guess would be that the falcon uses the 
same registers for compatibility but doesn't have the same hardware 
logic behind).

So unless someone has some documentations on the inner work of the 
falcon in that case, I don't think it's safe for now to create a 
Sound_HBL_Update function to call either crossbar_update_hbl or 
dma_snd_update_hbl.

For now, I prefer to add a check in dma_snd_update_hbl to return if the 
machine is not STE (I will rename it to include STE in its name) and I 
will enable the internal timer if the machine is in falcon mode.

regards

Nicolas



>
> The way you did it, falcon sound goes into dma_sound every HBL, and I
> really wanted to separate dma_snd and crossbar code.
> (I think also that dma_snd should be renamed to STEDMA_snd, or something
> like this to avoid confusion, as Falcon DMA sound is taken into account
> into the crossbar code).
>
> Do you agree with both points ?
>
> Regards
>
> Laurent
>
>
>
>
> Le 07/04/2011 23:31, Nicolas Pomarède a écrit :
>> Hello
>>
>> I committed a first round of patches that should improve sound quality
>> as well as accuracy.
>>
>> - use fixed values for dma sound freqs ; on STE, clock for dma sound
>> (as well as fdc or ym2149) is not the result of dividing the main 32
>> Mhz clock, but it uses a separate dedicated 8 Mhz clock (also,
>> dividing by 160,320,... doesn't give the right value anyway)
>>
>> - reorder / factorize some common code
>>
>> - handle programs that write in the sample buffer at the same time
>> this buffer is played by the DMA
>>
>> This last point is audible in the demo "Mental Hangover" for example
>> (very noisy sound output) as well as in the game "Power Up Plus"
>> (nearly no sound at all).
>>
>> In order to fix this, I updated the code to work in a similar way to
>> DMA sound on a real STE. On STE, the DMA sound uses a small 8 bytes
>> FIFO to store the next bytes to be sent to the DAC at the requested
>> output freq (50066, 25033, ...).
>> To keep this FIFO filled (you need approx 6.5 bytes per VBL at 50066
>> Hz stereo), the DMA sound has some bus accesses during the end of the
>> HBL (while the shifter doesn't need to read data to be displayed).
>> During those accesses, the DMA sound will read as many bytes as
>> necessary to get 8 bytes in the FIFO.
>>
>> This means that once the DMA read some bytes at the current sample
>> frame address, you can immediatly write some new bytes in the sample
>> buffer before this address, those addresses won't be read until the
>> sample loops.
>>
>> So, even if it's more complex than using double buffer, it's completly
>> possible to have a single buffer replay routine that generates new
>> samples at the same time it plays the rest of the buffer (this is
>> similar to how some demos work at the video level, where they use only
>> one video buffer and use some synchronisation with $ff8209 to be sure
>> there's no "conflict" with the data the shifter will read next (the
>> game Enchanted Lands works this way due to RAM limit to use double
>> buffer for video)).
>>
>> To emulate this way of processing DMA sound bytes, I added the
>> function DmaSnd_HBL_Update and call this function on every HBL in
>> video.c. This way, we now "read" sample data at the same video
>> position that the DMA does on STE (in the case of Hatari, I don't
>> handle a real 8 bytes FIFO, but this difference should not be hearable).
>>
>> Instead of generating ~500 samples in one go per VBL (for 25066 Hz
>> sound), we now generate small chunks of samples at every HBL. The most
>> important for this to work is that the total number of bytes per VBL
>> remains the same (but whether we generate one big chunk in one go or
>> 100 smallers chunks doesn't matter).
>>
>>
>> Let me know if you here some regressions. I'm not sure a lot of
>> programs will benefit from this fix, as using single buffer instead of
>> double buffer when generating sample is rather rare.
>>
>>
>> I still have some other patches pending to increase accuracy as well
>> as fixing the audio/video synchro problem reported in "More Or Less
>> Zero", but they require modifications to other parts than dmaSnd.c, so
>> it will take a little more time to clean.
>>
>>
>> PS : Anders, regarding the DMA sound FIFO, you once told me that doing
>> a stop/start to change sample address was messing with the overscan
>> timing (because the DMA will try to read 8 bytes in one go), but have
>> you ever tried to play 50066 Hz stereo sound during an overscan in
>> loop mode ? I'd like to know if this breaks the timings (with 230 or
>> 224 bytes per line)
>>
>>
>>
>> Nicolas
>> _______________________________________________
>> hatari-devel mailing list
>> hatari-devel at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/hatari-devel
>>
>>
>
> _______________________________________________
> hatari-devel mailing list
> hatari-devel at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/hatari-devel