[hatari-devel] Fixes for possible bug in dmasnd.c
Laurent Sallafranque
laurent.sallafranque at free.fr
Wed Apr 28 19:35:41 CEST 2010
Hello,
I think the sound_update should also be added here in crossbar.c
else if (dmaPlay.isRunning && ((sndCtrl & CROSSBAR_SNDCTRL_PLAY) == 0))
{
/* Turning off DMA play sound emulation */
+ sound_update();
dmaPlay.isRunning = 0;
dmaPlay.loopMode = 0;
nCbar_DmaSoundControl = sndCtrl;
memset(dac.buffer_left, 0, sizeof(dac.buffer_left));
memset(dac.buffer_right, 0, sizeof(dac.buffer_right));
}
Do you agree ?
If Yes, I can upload it tonight.
Regards
Laurent
npomarede at corp.free.fr a écrit :
> On Tue, 27 Apr 2010, Laurent Sallafranque wrote:
>
>> Hello,
>>
>>> 1) dma end address could sometimes be <= dma start address
>>
>> I think this is possible anyway or the real ste.
>> You can play "the whole memory if you put endframe < startframe"
>> This could be tested easily or a real Ste.
>
> Yes, I agree, on a real STE there's no "<=" comparison, the dma will
> just test that current address is "!=" from end address. Until this
> happens, dma sound will play.
> But as I don't have an STE, I don't know how the current address
> behave : does it loop at the end of the real RAM, does it loop when
> current address reach the maximum possible address on 24 bits (16 MB) ?
>
> If someone could test this on a real STE, we could emulate the correct
> behaviour, but for now it's certainly safer to "reject" such combination.
>
>>
>> Do you think there's something to do in the crossbar for this ?
>> Code is different, but startFrame and EndFrame are used here too.
>
> Yes, in Crossbar_setDmaPlay_Settings and
> Crossbar_setDmaRecord_Settings there's a test for "dmaPlay.frameLen <=
> 0" but as frameLen is Uint32 here too, this test will never work as
> expected.
>
> I will commit a similar change for this, but as for STE this is
> certainly something that should be allowed (even if don't think many
> programs are using "end <= start")
>
> Nicolas
>
>
>> npomarede at corp.free.fr a écrit :
>>>
>>> Hello,
>>>
>>> while running EPSS demo by Unit 17, I got the following crash of
>>> Hatari :
>>>
>>> #3 0xb7b9bb08 in __assert_fail () from /lib/i686/libc.so.6
>>> #4 0x08082b9d in CycInt_AddRelativeInterruptWithOffset
>>> (CycleTime=-3840, CycleType=1, Handler=INTERRUPT_DMASOUND,
>>> CycleOffset=0) at /home/npomarede/src/hatari-work/src/cycInt.c:377
>>> #5 0x08082ccb in CycInt_AddRelativeInterrupt (CycleTime=-3840,
>>> CycleType=1, Handler=INTERRUPT_DMASOUND) at
>>> /home/npomarede/src/hatari-work/src/cycInt.c:337
>>> #6 0x080835c0 in DmaSnd_StartNewFrame () at
>>> /home/npomarede/src/hatari-work/src/dmaSnd.c:283
>>> #7 0x0808397e in DmaSnd_EndOfFrameReached (nMixBufIdx=5532,
>>> nSamplesToGenerate=1) at
>>> /home/npomarede/src/hatari-work/src/dmaSnd.c:302
>>> #8 DmaSnd_GenerateSamples (nMixBufIdx=5532, nSamplesToGenerate=1)
>>> at /home/npomarede/src/hatari-work/src/dmaSnd.c:346
>>> #9 0x080a45eb in Sound_GenerateSamples () at
>>> /home/npomarede/src/hatari-work/src/sound.c:1049
>>> #10 Sound_Update () at /home/npomarede/src/hatari-work/src/sound.c:1081
>>> #11 0x0808384e in DmaSnd_InterruptHandler () at
>>> /home/npomarede/src/hatari-work/src/dmaSnd.c:476
>>> #12 0x080ce1d3 in m68k_run_1 (may_quit=1) at
>>> /home/npomarede/src/hatari-work/src/uae-cpu/newcpu.c:1755
>>> #13 m68k_go (may_quit=1) at
>>> /home/npomarede/src/hatari-work/src/uae-cpu/newcpu.c:1847
>>> #14 0x08098b55 in M68000_Start () at
>>> /home/npomarede/src/hatari-work/src/m68000.c:228
>>>
>>>
>>> After quite some time of debugging, I found 2 problems :
>>>
>>> 1) dma end address could sometimes be <= dma start address
>>> 2) after case 1) happened, hatari could crash
>>>
>>> First point happened because the dma sound end of frame's interrupt
>>> sometimes happened during the exact moment where the demo wrote some
>>> new values to dma start/end register. This means the new loaded
>>> addresses were partially wrong.
>>>
>>> In fact, around hbl 222, the program is doing "clr.b $ff8901 +
>>> move.b #3,$ff8901" to force an immediate reloading of the dma
>>> addresses. But in that case we should call SoundUpdate() when dma is
>>> stopped, to output all the samples that were generated up to hbl
>>> 222, else the next end of frame interrupt would happen near the
>>> start of the vbl, instead of hbl 222.
>>>
>>> When this happened and dma end <= dma start, there was a second
>>> problem with the test "dma.frameLen <= 0" because frameLen is
>>> unsigned. As this was not detected, frameLen was in fact something
>>> like 4 billions samples to play, and this could lead to a crash of
>>> Hatari.
>>>
>>>
>>> These fixes should correct the 2 bugs, but they should not
>>> improve/degrade sound quality as most of the time it would just have
>>> resulted in a crash.
>>>
>>> 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
>>
> ------------------------------------------------------------------------
>
> _______________________________________________
> hatari-devel mailing list
> hatari-devel at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/hatari-devel
>
More information about the hatari-devel
mailing list