Re: [hatari-devel] Sample frame buffer is incorrectly restarted

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 6.3.2024 19.26, Nicolas Pomarède wrote:
....
>   2) I don't understand why your TimerA function sets "muted=1", which 
> will briefly stop dma sound and start it just after. The whole point of 
> the DMA sound and timer A is that you can use it to seamlessly chain 
> audio frames without stopping/restarting DMA
>
> DMA will buffer the start/end addresses as soon as it start playing, 
> which will trigger the TimerA.
>
> So in TimerA you can immediately write the start/end address of the next 
>   frame, it will be buffered until the current frame is played and the 
> next frame should be started just after (you need to set "loop mode" for 
> this)
> you can even swap logical/physical buffer in TimerA instead of in main loop
>
> Then in your main loop you just have to monitor a variable that tells 
> you which buffer is actually playing and load data in the other buffer 
> (which will be swapped during TimerA)

This is Miro's test code for ScummVM audio playback.

Many ScummVM game engines are so slow that they do not have time to 
create a new frame in time.

If engine is only a slightly too slow / only occasionally misses 
providing a new audio frame in time, muting the audio instead of letting 
previous buffer to repeat, gives better speech output.

In some cases those occasional misses may take even tens of seconds 
(until engine has e.g. loaded/processed all data for a new section of 
the game), in which case muting buffer playback until there's again new 
buffer data, is much better.


	- Eero

PS. For really slow ScummVM game engines, that constantly fail to fill 
audio buffer in time, muting makes speech harder to understand than 
repeats, but as those games are already unplayable, it does not matter 
that much...