Subject: In addition, a reminder about the correct options

From: alankila
Date: Mon Apr 3 15:17:36 2006

To: Kohina-UADE-Forum
shd posted some suggestions about command line options to try.

I'd prefer the following:

uade123 --interpolator=sinc --filter=A1200E &lt;song&gt;
uade123 --interpolator=sinc --filter=A500E &lt;song&gt;

These two should yield the most accurate A1200 and A500 emulations, respectively. I hope shd agrees with me and removes the A500/A1200 versions and renames the *E versions (E stands for enhanced) in their stead.

---

From: shd
Date: Tue Apr 4 14:08:59 2006

To: Kohina-UADE-Forum
[quote:047339430a="alankila"]shd posted some suggestions about command line options to try.

These two should yield the most accurate A1200 and A500 emulations, respectively. I hope shd agrees with me and removes the A500/A1200 versions and renames the *E versions (E stands for enhanced) in their stead.[/quote:047339430a]

A500E uses 42% more multiplications than A500 mode. If there is no real audible gain, the faster one should be used. Hifists may configure a500e to uade.conf if they want.

So, for a500e to be the default, there will have to be two things:
 * songs where the difference is audible
 * users wanting the change

In addition, not too many people should be complaining about increased CPU usage. Unfortunately, it will be hard to make any users raise their voice on this. So we just have to wait for feedback.

What about a500/sinc, not a500e/sinc? Is sinc model somehow coupled with E-models in design? I hope not.

---

From: alankila
Date: Thu Apr 6 10:45:46 2006

To: Kohina-UADE-Forum
We have talked about this before on IRC, so here's the reminder.

The non-E versions were made against the old non-accumulating behaviour which simply waited 80 clocks and took sample and then waited another 80 clocks for the next and so on, thus discarding everything in-between. When working against that, I attempted to simply suppress the sampling noise produced by that design.

When I came up with the antialiasing interpolator model, where the sample is average of Paula's output during the 80-cycle period, I realized that I need to also redesign the filters again. Therefore, we have A500 and A500E mode. Because A500 and A1200 modes feature some sampling noise suppression, and because anti and sinc have quite little sampling noise -- the sinc mode in fact should have nothing whatsoever -- only the E modes should be used together with those interpolators.

(A technical point for audience: we talk about interpolation quite often here, but it is actually resampling. The antialiasing mode is a simple boxcar FIR convolution, with small artifacts produced by its design but it is very, very cheap to run, while the sinc is theoretically correct but much more expensive.)

For me, it's not an issue of performance but of correctness. That being said, the audible difference between A500 and A500E is quite small; regardless I haven't spent any time improving the A500 or A1200 filter models after designing them with a program that had a grievious bug which took me a long time to hunt down. I suspect some improvements could be made also to the old code. However, I don't see any point to do so; the antialiasing or sinc modes are a much better starting point, and usability-wise the existence of the older options only serves as traps for the unwary.

As to performance, it pays off to keep in mind that we run the filter code only 44100 times per second. Whether the code has to do 150 000 more multiplications (it does something like 300 000 to begin with) per second on top of all the work it does to run amiga emulation, doesn't work out to large percentage difference in cpu usage. The sinc code is much more expensive and actually nearly doubles CPU usage -- I can understand using performance as argument against making that default. However, the difference between A500 and A500E seems quite hard to measure; I believe you need to make a few dozen runs and produce statistical numbers to see it *at all*.

---

From: shd
Date: Thu Apr 6 11:07:07 2006

To: Kohina-UADE-Forum
[quote:3f7ac86be8="alankila"]
When I came up with the antialiasing interpolator model, where the sample is average of Paula's output during the 80-cycle period, I realized that I need to also redesign the filters again. Therefore, we have A500 and A500E mode. Because A500 and A1200 modes feature some sampling noise suppression, and because anti and sinc have quite little sampling noise -- the sinc mode in fact should have nothing whatsoever -- only the E modes should be used together with those interpolators.
[/quote:3f7ac86be8]

The last phrase makes sense if we try to achieve best possible result, but it is not my goal. I hate wasting CPU cycles, so my goal is good enough with little waste. I admit 42% more multiplications is not much with current computers, but it is relevant in slow devices. I believe each part of the operating system has to be optimized: optimizing each part by x% makes the whole OS x% faster.

Antialiasing (anti) interpolator does make sense even with A500, because A500 without interpolation clearly suffers from huge antialiasing: 28 kHz sampling rate amounts to ~128 paula cycles per sample, and output gets a sample once every 80 paula cycles. The maximum frequency is the worst case, but we need to minimize error in that situation as well.

---

From: alankila
Date: Thu Apr 6 15:04:04 2006

To: Kohina-UADE-Forum
Well, achieving the right result is a parameter for me. I find it somewhat ludicruous that we are arguing about a 4 multiplications per sample, but I concede that if you go to weak enough hardware it matters. However, by that point a lot of other stuff matters *more*.

The issue here is largerly with the LED filter simulation that uses 6 multiplications because that filter still seems quite hard to duplicate digitally. It's no secret that I'm not perfectly happy with it, I merely stopped optimizing it at some point. Perhaps if I looked, I might find a way to do it with smaller cost.

I also have made some work towards making the filter sampling rate independent. I've largerly examined the behaviour of the filters in a wide range of sampling frequencies and I believe I can make the filters behave well over at least 32 kHz to 96 kHz sampling frequencies. It seems that a correction is required to adjust the lowpass cutoff frequencies when the cutoff point gets close to the nyquist frequency.

Of course, the only practical sampling rates are 44.1 kHz and 48 kHz, and for those I can make the filters behave as desired for the audible spectrum, correction or not. However, 96 kHz and 32 kHz rates might be interesting as test cases if nothing else.