[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