Re: [hatari-devel] STe DMA sound

[ Thread Index | Date Index | More Archives ]

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.


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)


Mail converted by MHonArc 2.6.19+