Re: [hatari-devel] STe DMA sound

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 15/04/2018 à 09:48, Vincent Rivière a écrit :
> On 15/04/2018 at 08:33, Vincent Rivière wrote:
> > With proper traces in YM emulation, I guess we could understand why that
> > tune plays...
>
> After having added some traces...
>
> If I'm not mistaken, the 7 KHz artifact appears when Lethal Xcess sets 
> the period of voice C to 0 (by writing 0 to YM registers 4 and 5), while 
> keeping the voice enabled (register 7).
> This might be a Lethal Xcess bug. AFAIK, such mode should only be 
> enabled to play samples. Maybe some leftover of ST digidrums.
> I'm not sure what is supposed to happen on real ST in that case.
>
> In sound.c, function Sound_WriteReg().
> I cases 4 and 5:
> As a test, I forced "ToneC_per = 0;".
> In that case, the music disappears, but the high-pitched artifact remains!
> So the issue is definitely somewhere near that place.
>
> Finally, I'm not sure if there is really a problem with STe DMA...
> But with the lack of YM digidrums on STe, certainly.
>
> I'm sorry, the problems goes beyond my understanding of Hatari code, and 
> I have no more time...
> But I'm sure we are now looking to the right direction.

Hi

the fact that the game still sets period=0 when using dma sample looks 
indeed like a bug ; this should be needed only when using mfp timer to 
play sample using volume modulation with the YM.
When using dma sample volume of voice C should be just set to 0 instead.

Using per 0, 1, 2 and 3 will give problem because it's the equivalent of 
125 kHz, 62.5 or 41 kHz square wave. Considering that most audio cards 
will output sound at 44.1, nyquist freq will be 22 kHz, so any freq 
component above 22 kHz will be altered more or less.

In Hatari 2.0 and before, there was a special case where "per <= 6" was 
"replaced" by a continuous signal instead of a square wave, which 
removed these artefacts (but gave a non accurate result compared to real YM)

But in Hatari 2.1, ym2149 emulation is now cycle exact and produce a raw 
250 kHz sound output, containing all frequencies/periods (which is 
important to emulate some specific cases using low periods). The 250 kHz 
sample is then downsampled to the audio card output freq (44.1 kHz for 
example).

This is the tricky part ; there're tons of ways to do this, some very 
fast, some really slow (see audacity's quality parameter when 
downsampling for some examples).

For now, Hatari uses 2 methods to downsamples :
 - YM2149_Next_Resample_Nearest : simple "closest" sample choice, fast 
but will give aliasing
 - YM2149_Next_Resample_Weighted_Average_2 : interpolation of previous 
and next sample. This works quite well for low periods, but not for very 
low such as 1,2 or 3.
 - YM2149_Next_Resample_Weighted_Average_N : this is the missing 
function that was not available yet for Hatari 2.1 (no time to complete 
at this time when 2.1 was released)

For example, with per=0, you need to average approx 6 input samples to 
get 1 output sample. Weighted average on only 2 samples will not be 
enough to filter correctly, which might explain the 7 kHz freq you see 
in the result.

I will try to complete "Weighted_Average_N" in the next days/weeks, this 
might fix the problem (in all cases doing an average on "n" samples is 
needed for very low period, even if in most cases "n" will be 2 because 
it's very rare that period <= 6 are used)

Nicolas