Possibilities for integer audio scaling to minimize aliasing

[Dr.Venom]

Hi Toni,

This post has gotten a bit long. If you're short of time, could you possibly look at the 4 assumptions listed towards the end of this post and the request.

Here goes..

Still on the topic of sound aliasing with the current implementation. I'm trying to achieve the minimum amount of sound aliasing without using interpolation in the current WinUAE.

Since the topic itself is quite complicated, I'm wondering if the below analysis makes sense?

From the UAE readme it says:

sound_interpol=type [default none]
Normally, sound samples are output exactly as they are computed, without any post-processing. This can generate errors in the sound output when the output frequency isn't an even multiple of the input frequency. These errors are usuable perceived as a high-frequency noise.

To make that a bit more lively I think the parallel with video scaling seems appropriate:

When you're scaling the native Amiga video output non-integer without interpolation, there will be scaling artifacts in the video output. These are mostly seen as uneven or "jaggy" lines, or, when using interpolation as a blurry image. I think we all know examples of how that looks like.

Accordingly when we are scaling native audio output non-integer without interpolation we will get audible artifacts in the audio, similar to the "jaggy lines" in non-integer scaled video output. The best example I found of aliasing sound is the Sawtooth aliasing demo (click link below and then play on ogg example).

Three notes are played, alternating between no aliasing and aliasing:
Sawtooth aliasing demo

Pretty scary how much aliasing degrades the sound quality in above example..


Possibilities for integer audio scaling to minimize aliasing

So, as I understand it currently, to minimize aliasing in the WinUAE sound output we have different options:

1. Integer scaling of input to output (PC host) frequency
2. Interpolation of sound when there's non-integer scaling (Sinc, Anti?)
3. Reproduction of analog filter stage (A500 and A1200 (emulated) filter)

For now I would like focus on point 1 solely (point 2 and 3 have been taken care of in WinUAE already, even though they may not be perfect..)

To be perfectly honest this is not my field of expertise, so the only thing I can go by is making some assumptions.


Assumption 1:
From what I understood from the interpolate.txt the audio buffer is filled by decimating the Paula signal. This means it discards samples until it arrives at the correct output rate.

decimate the signal by discarding samples until we obtain output at the correct rate. For 44.1 kHz output we need to discard approximately 79 of every 80 samples.

(Said differently: keep approximately every 80th sample.)

Assumption 2:
Discarding samples at a perfectly even rate leads to less aliasing than discarding at an uneven rate. I.e. keeping every 80th sample always exactly is better than keeping the 79th, 80th and 81th in an alternating fashion to keep the average at 80.

To discard at a perfectly even rate, the Paula output rate should be an integer multiple of the PC Host output rate.

Clearly that is not the case:

Paula    Soundcard    Ratio
3546895    44100    80,42845805
3546895    48000    73,89364583
3546895    96000    36,94682292
3546895    192000    18,47341146
3546895    384000    9,236705729

Since the PC output rates are fixed, the only way to make this fit (divisble at an integer rate) is adjusting the Paula rate.


Assumption 3
The Paula rate in WinUAE vsync mode is adjusted for the difference between [PC host video refresh / Native Amiga refresh]

So given that in WinUAE the Paula audio rate follows the PC host vsync rate (when is vysnc mode at least), we only need to find the target PC video refresh rate to have an integer divisible rate for Paula versus PC host output rate:

Paula     Soundcard     Ratio  Closest Int.   Adj. Paula     Adj. Paula Ratio     Agnus LOF     Paula Ratio * Agnus LOF         
3546895     44100     80,42846     80         3528000     0,994672805369203000     49,92040928350     49,6544735471978000         
3546895     48000     73,89365     74         3552000     1,001439287038380000     49,92040928350     49,9922590815324000         
3546895     96000     36,94682     37         3552000     1,001439287038380000     49,92040928350     49,9922590815324000         
3546895     192000     18,47341     18         3456000     0,974373360361668000     49,92040928350     48,6411169441937000         
3546895     384000     9,236706     9         3456000     0,974373360361668000     49,92040928350     48,6411169441937000

Sorry for the messy table, but there seems no proper way of pasting an excel table in this forum.

The conclusion is that to be able to discard paula samples at a perfectly even rate we need to increase the Agnus video refresh rate from its default LOF rate of 49,9204092835Hz to 49,9922590815324000Hz.

If we do this the Paula output rate rises equivalently to 3552000Hz and for both the PC output frequencies 48Khz and 96Khz we have an integer fraction of Paula output versus PC host output rate of 74 and 37. Or in other words at that video refresh rate we can discard audio samples at a perfectly even rate.


Assumption 4

Setting the displayrate in WinUAE to:

displaydata_pal=49.9922590815324,locked,pal

raises Paula audio rate to exactly 3552000Hz, which for both 48Khz and 96Khz PC output rate makes discarding audio samples at a perfectly even rate possible. Or in other words (assumption!) decreases the amount of aliasing in the PC host audio output.

Request:

Toni, currently it is not possible to precisely set

displaydata_pal=49.99225908153240

as the refresh rate gets truncated. This happens both when you try to set this rate in the GUI or through the config file. Could you possibly allow this precision to be set for the displaydata refresh rate?

[DROWSYNET]

Originally Posted by Dr.Venom

Hi Toni,

This post has gotten a bit long. If you're short of time, could you possibly look at the 4 assumptions listed towards the end of this post and the request.

Here goes..

Still on the topic of sound aliasing with the current implementation. I'm trying to achieve the minimum amount of sound aliasing without using interpolation in the current WinUAE.

Since the topic itself is quite complicated, I'm wondering if the below analysis makes sense?

From the UAE readme it says:
To make that a bit more lively I think the parallel with video scaling seems appropriate:

When you're scaling the native Amiga video output non-integer without interpolation, there will be scaling artifacts in the video output. These are mostly seen as uneven or "jaggy" lines, or, when using interpolation as a blurry image. I think we all know examples of how that looks like.

Accordingly when we are scaling native audio output non-integer without interpolation we will get audible artifacts in the audio, similar to the "jaggy lines" in non-integer scaled video output. The best example I found of aliasing sound is the Sawtooth aliasing demo (click link below and then play on ogg example).

Three notes are played, alternating between no aliasing and aliasing:
Sawtooth aliasing demo

Pretty scary how much aliasing degrades the sound quality in above example..


Possibilities for integer audio scaling to minimize aliasing

So, as I understand it currently, to minimize aliasing in the WinUAE sound output we have different options:

1. Integer scaling of input to output (PC host) frequency
2. Interpolation of sound when there's non-integer scaling (Sinc, Anti?)
3. Reproduction of analog filter stage (A500 and A1200 (emulated) filter)

For now I would like focus on point 1 solely (point 2 and 3 have been taken care of in WinUAE already, even though they may not be perfect..)

To be perfectly honest this is not my field of expertise, so the only thing I can go by is making some assumptions.


Assumption 1:
From what I understood from the interpolate.txt the audio buffer is filled by decimating the Paula signal. This means it discards samples until it arrives at the correct output rate.

(Said differently: keep approximately every 80th sample.)

Assumption 2:
Discarding samples at a perfectly even rate leads to less aliasing than discarding at an uneven rate. I.e. keeping every 80th sample always exactly is better than keeping the 79th, 80th and 81th in an alternating fashion to keep the average at 80.

To discard at a perfectly even rate, the Paula output rate should be an integer multiple of the PC Host output rate.

Clearly that is not the case:

Paula    Soundcard    Ratio
3546895    44100    80,42845805
3546895    48000    73,89364583
3546895    96000    36,94682292
3546895    192000    18,47341146
3546895    384000    9,236705729

Since the PC output rates are fixed, the only way to make this fit (divisble at an integer rate) is adjusting the Paula rate.


Assumption 3
The Paula rate in WinUAE vsync mode is adjusted for the difference between [PC host video refresh / Native Amiga refresh]

So given that in WinUAE the Paula audio rate follows the PC host vsync rate (when is vysnc mode at least), we only need to find the target PC video refresh rate to have an integer divisible rate for Paula versus PC host output rate:

Paula     Soundcard     Ratio  Closest Int.   Adj. Paula     Adj. Paula Ratio     Agnus LOF     Paula Ratio * Agnus LOF         
3546895     44100     80,42846     80         3528000     0,994672805369203000     49,92040928350     49,6544735471978000         
3546895     48000     73,89365     74         3552000     1,001439287038380000     49,92040928350     49,9922590815324000         
3546895     96000     36,94682     37         3552000     1,001439287038380000     49,92040928350     49,9922590815324000         
3546895     192000     18,47341     18         3456000     0,974373360361668000     49,92040928350     48,6411169441937000         
3546895     384000     9,236706     9         3456000     0,974373360361668000     49,92040928350     48,6411169441937000

Sorry for the messy table, but there seems no proper way of pasting an excel table in this forum.

The conclusion is that to be able to discard paula samples at a perfectly even rate we need to increase the Agnus video refresh rate from its default LOF rate of 49,9204092835Hz to 49,9922590815324000Hz.

If we do this the Paula output rate rises equivalently to 3552000Hz and for both the PC output frequencies 48Khz and 96Khz we have an integer fraction of Paula output versus PC host output rate of 74 and 37. Or in other words at that video refresh rate we can discard audio samples at a perfectly even rate.


Assumption 4

Setting the displayrate in WinUAE to:

displaydata_pal=49.9922590815324,locked,pal

raises Paula audio rate to exactly 3552000Hz, which for both 48Khz and 96Khz PC output rate makes discarding audio samples at a perfectly even rate possible. Or in other words (assumption!) decreases the amount of aliasing in the PC host audio output.

Request:

Toni, currently it is not possible to precisely set

displaydata_pal=49.99225908153240

as the refresh rate gets truncated. This happens both when you try to set this rate in the GUI or through the config file. Could you possibly allow this precision to be set for the displaydata refresh rate?

I'm surprised that no one ever replied to this post, since it addresses a major concern when it comes to dealing with emulation of the Paula chip. Something that occurs to me is that the aliasing we hear in the emulation is introduced by the interpolation between the raw output data of the emulation -> the output of the host device's sample rate, not the emulation itself.

Let's assume that the emulation is able to perfectly represent the signal chain of the Paula chip all the way to the output of the RCA ports. You get:

- Initial clock rate of 3546895 -> emulated signal path -> output

[A transitional environment between this virtual output and the environment of the machine running WinUAE]

- The clock rate of the host - 44.1khz, 48khz, 96khz, etc.

While this doesn't resolve the problem of aliasing in real-time applications (listening on headphones, speakers), that distance between the two audio destinations could give us room to intercept this raw signal before it is interpolated to match the host machine. From here, that signal could be recorded to an uncompressed file format for any audio editor with granular control over sample rates - like Adobe Audition.

Ultimately, listening to Amiga audio on any modern device introduces the problem of aliasing since no computer does run at the Paula's native sample rate, but at least to preserve that signal would be very useful in case someone wanted to build custom hardware to output the signal with 1:1 accuracy.

The bigger issue as I understand it is that there may never be a way to accurately model Paula's input through emulation, since decimation when going in opposite order (host machine -> WinUAE sampler input) is unavoidable. This may only ever be achievable by the original hardware. Would love to get the thoughts of someone who works in this domain, as I'm also making a lot of assumptions in my response.

[rutra80]

Interesting indeed. I'm no guru either but exclusive WASAPI outputs at the rate of source, no idea if it can achieve Paula frequency though. Anyway, Paula-emulation-PC-DAC-speakers chain is not that simple - there's a lot of oversampling in DACs. Also sound isn't quite like video - it's not quite possible at the end of the chain to have constant DC (like white or black in video), even perfect square waves are not quite possible. Even if emulation would be more perfect, it still would get different on PC side or at most at external DACs, than it was on real Amiga

[lifeschool]

Hi guys,

I dont know if this is a related issue, but I have been having problems with Sampled Audio Disks. If the raw sample is played in one go, the sound glitches on initialisation but otherwise plays fine. But, if the sample stops and starts again, it glitches at the start of each sample - like a 'crashing' sound rather than a high pitch buzz?

This is strange, because if I type the commands from CLI, like 'Play XYZ', it works without glitches. The samples themselves play in sample editors and normally without glitches. So its not the samples, or the commands. Its almost like there is something tripping over itself when playing samples close together?

I've attached a Noddy demo which demonstrates this, tested with UAE 4.4 and also 2.0. There are many other sample disks with this issue, such as Smith and Jones, Not The 9 o clock News, and New Order Remixes.

Is this something to do with Cycle Exact? Or maybe the Auto Scalling on my screen is messing with the timings? Audio buffers seem to make no difference.

I know this is my emulation setup causing this issue, but I cant figure out where I went wrong...

[spiff]

If we're speculating about limiting aliasing;

If the source (game/mod) sample is 8 bit arbitrary "low" rate with plenty of quantization, wouldn't it make sense to insert dithering at this stage? Noise shape that and then anything that comes out would have an order of less quantization compared to anything created by sampling paula.

Or are we striving towards as correctly as possible reproduce unintentional quantization created from the source.. by reducing aliasing?

[rutra80]

Original poster meant about additional aliasing introduced by the difference between how Amiga & PC audio works. Amiga had 4 rate-independent channels while PC at the end always resamples to one rate. Interpolation takes care of this stuff but every method has its good and bad sides (btw, does WinUAE use BLEP synthesis?). No interpolation is closest to the original sound but it may introduce additional aliasing when PC rate doesn't have common denominator with all of 4 Amiga channels. I wonder if it's audible though...
Also if I understand correctly we are talking here about discrepancies in sampling rates, while dithering helps with discrepancies in bit depth.

With WASAPI Exclusive it should be possible to set PC output to any (integer?) rate up to what hardware supports.

I'd say WinUAE should be able to output as close to original Amiga sound as possible, along with original Amiga quirks. Then there should be options to "correct" it (interpolation, maybe dithering, etc.).