22 October 2018, 16:19 | #1 | ||
Registered User
Join Date: Jul 2008
Location: Netherlands
Posts: 485
|
Possibilities for integer audio scaling to minimize aliasing
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: Quote:
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:
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. Quote:
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: Code:
Paula Soundcard Ratio 3546895 44100 80,42845805 3546895 48000 73,89364583 3546895 96000 36,94682292 3546895 192000 18,47341146 3546895 384000 9,236705729 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: Code:
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 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? Last edited by Dr.Venom; 22 October 2018 at 16:41. |
||
09 September 2020, 00:06 | #2 | |
Registered User
Join Date: Sep 2020
Location: Washington, DC USA
Posts: 8
|
Quote:
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. |
|
10 September 2020, 10:36 | #3 |
Registered User
Join Date: Jul 2019
Location: Poland
Posts: 308
|
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
Last edited by rutra80; 11 September 2020 at 21:38. |
11 September 2020, 16:11 | #4 |
Local Moderator
Join Date: Oct 2009
Location: Lancashire, UK
Age: 48
Posts: 1,591
|
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... |
11 September 2020, 23:50 | #5 |
Oh noes!
Join Date: Mar 2003
Location: Neverland
Posts: 766
|
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? |
13 September 2020, 20:33 | #6 |
Registered User
Join Date: Jul 2019
Location: Poland
Posts: 308
|
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.). |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Tweaking Auto Integer Scaling Further | Lobotomika | support.WinUAE | 10 | 29 July 2014 17:54 |
Programmed modes and integer scaling | Leandro Jardim | support.WinUAE | 5 | 17 April 2014 12:35 |
Integer Scaling | FreakyDan | support.WinUAE | 3 | 12 May 2012 15:43 |
Integer scaling bug | Leandro Jardim | support.WinUAE | 2 | 14 February 2012 20:46 |
WinUAE Integer Scaling Crash | Schlachtwerk | support.WinUAE | 1 | 11 November 2011 17:04 |
|
|