View Single Post
Old 02 July 2014, 19:56   #5
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,518
Next beta will have option to force audio hack even if CPU mode is not "fast enough". Perhaps it will help..

There is nothing special in audio hack. It does three things:

1:

Old behavior: When audio DMA is switched off, audio channel was forced to idle state immediately.

New: When audio DMA is switched off, flag is set that program wants to switch off DMA, if program re-enables DMA and flag is still set, channel is forced to idle state. Flag is cleared when channel becomes idle (forced or period has counted down)

This fixes most programs that have audio DMA CPU delay loops and still allow (badly done) programs that really need delay before channel goes to idle state. Most common bug is to switch DMA off, then clear INTREQ and finally wait for interrupt bit to be set (which happens when period has counted down)

If program does not wait for idle channel, attempting to play new sample does nothing. Old sample keeps playing, only period changes.

2:

If channel is idle and program writes to AUDxDAT and period is less than 10, play nothing, go back to idle state immediately. This works around audio.device weirdness which is not that compatible with very fast CPUs (JIT).

3:

If program writes to audio pointers (high or low word) immediately after DMA has been enabled but before Agnus has seen DMAL DSR bit from Paula (Agnus has not latched channel's audio pointer): force latching immediately. This hack assumes that program wanted to update only pointer register, instead of updating current sample pointer immediately (and playing from new address)
Toni Wilen is offline  
 
Page generated in 0.05387 seconds with 9 queries