|Re: [hatari-devel] STe DMA sound|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel 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
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
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)