Re: [hatari-devel] DMA sound and Falcon

[laurent.sallafranque@xxxxxxx]

> I can fix this issue rather easily, I just need to take CpuFreqShift 
into account, but it won't fix the case where starting the same program 
at 16 Mhz sometimes gives correct sound and sometimes gives noisy sound.


Yes, that's what I expect for now.
I have more hope with the 68030 CPU improving (later) and memory access timings (later again).

Regards
Laurent


----- Mail original -----
De: "Nicolas Pomarède" <npomarede@xxxxxxxxxxxx>
À: hatari-devel@xxxxxxxxxxxxxxxxxxx
Envoyé: Lundi 12 Septembre 2016 14:15:24
Objet: Re: [hatari-devel] DMA sound and Falcon

Le 12/09/2016 à 12:28, laurent.sallafranque@xxxxxxx a écrit :
> Hi Nicolas,
>
>
>> I need to make more modifications to crossbar.c, this is because
> crossbar.c uses CPU_FREQ to compute the frequency ratio, but I don't
> think it shouldn need to do that. Only the requeted freq and the host
> output freq should be needed.
>
> I'm not that sure. For the STe emulation, this is OK, because the sound can only go to the "sound output".
>
>
> In the falcon emulation, the sound has to be generated in "real time", because the DMA out sound can be redirected to the DSP input sound (for example) and the DSP is a "real time" componant that computes data given by the CPU, the crossbar, ...
>
> The crossbar matrix has to be feed at constant speed accordingly to the CPU and DSP speed. (I mean "in real time" because you can't manage all the data at once at the end of the VBL for example, the DSP would be stocked waiting for datas from the crossbar or would get "zero" values)
>
> That's why I always say that the sound accurancy in the Falcon part is dependant of the accuracy of the CPU (in falcon mode).
>
>
> As there has been a big change of CPU (old winuae CPU vs new winuae CPU), and I've notices that the timings are really different between the 2 cores, may this explain the degradation in sound quality ? (maybe...)
>

Hi

with the small sound test program you sent me, the quality is sometimes 
(randomly) very noisy even with Hatari 1.8, so I don't think the quality 
problem is related to the change I made recently to count cycle, it's an 
old problem.

What can happen if my changes went bad is that sound will play at the 
wrong speed, but with the same quality. This is what we see here, where 
it's x2 too slow or x2 too fast when you switch to 8 or 32 MHz.

I can fix this issue rather easily, I just need to take CpuFreqShift 
into account, but it won't fix the case where starting the same program 
at 16 Mhz sometimes gives correct sound and sometimes gives noisy sound.

Nicolas