Program execution speed

[Gramofonik]

30M Taps, All Options: ON Intel Ultra 7, DDR 5600 MHZ - 16 GB Windows 11 64bit
approximately 0.4 × the duration of the recordings (2.5x)
Intel Ultra + GPU integrated graphics (integrated with the processor) - Speed ​​boost of around 10–15%
Intel Ultra 7 + GPU Geforce RTX 5060 TI - 0.1 - 0.11 x the duration of the recordings (9-10x)

1. Will increasing the memory from 16 GB to 32 GB improve processing speed? When the program is launched, approximately 10–11 GB of memory is available in the system.
2. Will upgrading the graphics card from an RTX 5060 Ti 8 GB to an RTX 5060 Ti 16 GB increase the program's performance speed?

[ToxaDev]

That is a very useful set of measurements — thank you. Before answering the
upgrade questions properly, could you send one session log? It would replace
a lot of guesswork on my side.

%LOCALAPPDATA%\AuraEngine\logs\
latest-session.txt in that folder points at the newest one.

Ideally a run of two or three tracks of different lengths — say one around
3 minutes and one around 6-7 minutes — on the settings you actually use.

Every line in it is timestamped, so it tells me three things I currently have
to guess at: which adapter the engine really opened, whether any file fell back
to the CPU part-way through, and where the time actually goes per stage. One
number in your results makes me want to check that: a 10-15% gain from the
integrated GPU is lower than it should be if the card were genuinely doing the
convolution, and your earlier crash reports show it was running out of memory
on that hardware at least some of the time.

Also worth knowing: are you on the 30M bundle now? Your crash reports came from
the 10M one, and the two ask the graphics card for different amounts of memory.

[Gramofonik]

AE 1.26
30M taps, All DSP: ON.
I am using an RTX 5060Ti 8GB GPU.
Processor: Intel Ultra 7; Memory: 16GB.
14 files, total duration 3179s
Ordered 1 to 14, encoding time 348s

The encoding process was a bit faster.
However, there are still moments where the system waits for available memory.
I’m buying an extra 16GB next week and will run another test.
From what I can see, the issue lies in the interaction between the GPU and the CPU.
A new GPU encoding task doesn't start until the CPU encoding task has finished.

session-2026-09-11_20-51-11.log

[Gramofonik]

AE 1.26
30M taps, All DSP: ON.
I am using an RTX 5060Ti 8GB GPU.
Processor: Intel Ultra 7; Memory: 16GB.
14 files, total duration 3179s
Ordered 14 to 1, encoding time 324s

A CD holds 80 minutes of audio (plus a 2-minute margin, just to be safe).
Wouldn't it be better if the program first performed the GPU conversion in 80-minute batches, followed by the actual encoding and FLAC verification?
If the Vulkan limit is 1433 MB, a GPU with 8 GB of memory could encode up to five files at once.
When I encode WAV to FLAC, I use dBpoweramp, which encodes all the files simultaneously rather than one by one; it’s very fast.

session-2026-09-11_21-22-59.log

[ToxaDev]

Thank you for testing it the same day, and for running it both ways round — that is what makes the numbers usable.

Your figures, against your 1.2.5 runs:

14 -> 1     391 s  ->  324 s     -17.1%
1  -> 14    371 s  ->  348 s      -6.2%
mean        381 s  ->  336 s     -11.8%

Less than the 23.5% I measured here, and that difference is itself informative: on my machine the encoder was a bigger share of the work, while on yours more of the time sits in the convolution and in waiting for memory. So you got the part of the improvement that applies to you.

You have diagnosed it correctly

A new GPU encoding task doesn't start until the CPU encoding task has finished.

That is exactly right, and it is the main thing wrong with the pipeline. Your earlier logs let me measure it: your RTX 5060 Ti is busy about 35% of a batch. It spends most of its time waiting for the processor to finish with the previous file.

So your instinct to separate the two — convert on the card first, encode afterwards — is the right shape. It is close to what I am building, though the reason it cannot be done yet is not the one you would expect.

One correction, because it changes what to buy

If the Vulkan limit is 1433 MB, a GPU with 8 GB of memory could encode up to five files at once.

The 1433 MB is a video-memory figure, and video memory is not what is stopping you. Your logs show it was never exhausted once — no refusals, no fallbacks. Your card could indeed hold several files at a time.

What stops you is ordinary system memory. Each file needs about 4.5 GB while it is being processed, and with 16 GB installed there is only room for one or two at a time. That is the "waiting for memory" message: the program declining to take memory Windows needs rather than pushing your system into swapping.

So the extra 16 GB you have ordered is the right purchase, and a bigger card would not have been.

Why it needs that much, and what I am fixing

Hybrid-Phase convolves each file twice — once linear phase, once minimum phase — and then blends the two together where it detects attacks. Right now both complete results have to exist in memory before the blend can start. For a four-minute track that is about 2.7 GB of the 4.5.

The fix is to blend each piece as it comes out of the second convolution instead of waiting for all of it, so the second copy never exists. That takes the peak to roughly 3 GB, which is what will let a second file genuinely run alongside the first on a 16 GB machine — and, once files stop queueing behind each other, the card stops idling between them. Your observation and this fix are the same problem seen from two ends.

It is a change inside the audio path, so it is getting its own release with proper equivalence testing rather than being hurried.

On dBpoweramp

Fair comparison, and worth being precise about. It encodes many files at once because encoding is all it does. Here encoding is one of six stages, and since 1.2.6 it is already parallel internally — each file's four compression candidates are now fitted simultaneously, and up to three files run at once where the processor allows. What holds it back is not how the encoding is scheduled but how much memory a file in flight needs, which is the part above.

When your extra memory arrives I would be interested in the same 14-file test again. If the waiting messages disappear and the time drops noticeably, that tells me the memory work will pay off; if they persist, that tells me something I have not thought of yet.

[Gramofonik]

Hello,
Once I get the extra 16GB of RAM, I’ll run a test.

I just ran a test encoding a WAV file—[AE · 44.1k→352.8k · Kaiser 30M · f64 · AA · HP]—to FLAC level 5.
The same files used for testing were used here.
Intel Ultra 7 processor. dbpoweramp Converter
Encoding time: 7 seconds.
Without verification.

[ToxaDev]

That is a useful measurement, and it says something slightly different from
what it looks like at first. Thank you for running it.

Your 408x is an aggregate: dBpoweramp took all fourteen files at once and got
through 3179 seconds of audio in about 7.8 seconds of wall clock. What matters
for comparison is the rate per file, and there the picture changes.

From your own 1.2.6 logs, our encoder averages 7.1 seconds per file (6.61 s and
7.53 s across your two runs). Your files average 227 seconds of audio each:

AuraEngine   227 s of audio in 7.1 s  =  32x real time per file
dBpoweramp   227 s of audio in 7.8 s  =  29x real time per file

So per file we are not slower — marginally faster, in fact, while doing more
work per block: we fit four predictor orders and keep the smallest, where level
5 does not search that way.

The whole difference is how many files are in flight. dBpoweramp ran fourteen;
we run three. That is the same limit we have been talking about, seen from a
new angle — and your measurement is the cleanest evidence yet that the encoder
itself is not what is holding the batch back.

One caveat on my arithmetic: I am assuming those 7 seconds cover all fourteen
files, and I do not know how many threads dBpoweramp used. If it was one file
at a time, the comparison changes and I would like to know.

Worth saying plainly: those three files at once are limited by memory, not by
the processor. That is what the extra 16 GB should change, and why I am
interested in your test when it arrives.

[Gramofonik]

Time: 3179s (14 track)
Intel Ultra 7+ GPU RTX 5060TI (C: 3008MHz/ M: 1788MHz)
Memory 16GB (available 11 GB)
The configuration of available options is the same in each case.
ALL DSP: ON / FS Multiper: FS 8x
30M Taps: 10.15x
10M Taps: 13.76x
1M Taps : 19.38x

In the 30M and 10M cases, there are momentary pauses in CPU processing due to waiting for system memory to be freed.
Version 1.26 processes up to two threads simultaneously. Another test after increasing system memory by an additional 16 GB.

Time: 3179s (14 track)
Intel Ultra 7+ GPU RTX 5060TI (C: 3008MHz/ M: 1788MHz)
Memory 32GB (available 25 GB)
The configuration of available options is the same in each case.
ALL DSP: ON / FS Multiper: FS 8x
30M Taps: 15.07x Increase in speed + 48,5%
10M Taps: 17.07x Increase in speed+ 24,05%
1M Taps : Increase in speed 23.59x + 21,71 %

ONLY CPU 30 Taps: 5.72x

1. In the +GPU option, there is no waiting for memory.
   Three threads are active. Perhaps it would be worth launching four threads instead of running them simultaneously?
2. When only the CPU is working, there is a wait for memory.
3. There is a significant increase in performance.

session-2026-09-15_19-23-10.log
session-2026-09-15_19-18-19.log
session-2026-09-15_18-56-33.log
session-2026-09-15_18-48-38.log

[ToxaDev]

1.2.9 is up, and the queue your logs uncovered is gone.

https://github.com/ToxaDev/aura-engine/releases/tag/v1.2.9 — the 30M bundle is
the same one you are using. Unpack it into its own folder rather than over the
old one.

What your logs showed, and what changed

With 32 GB you stopped waiting for system memory, and a different queue came
into view behind it: the engine's own limit on how much of the card it would
use. It assumed 1433 MB — a Vulkan limit on one buffer, not a measurement of
your card — and one convolution at 30M taps takes 736 MB, so it let a single
file onto the card at a time. In your 30M runs, 145 of the 224 convolutions
had to wait there: 160 seconds of waiting, added up across the three files, in
a 211-second batch.

The engine now asks Windows how much video memory is actually free, and how
much every program together is holding, and plans against three quarters of
the smaller number. Your 8 GB card should report something over 5 GB free —
room for all of them.

And four files at once

The three-file limit was measured back when only one convolution could be on
the card, where a fourth file could only lengthen the queue. With the queue
gone, it pays. Measured here on 13 files, 30M taps, all DSP on:

32 logical cores   3 files  177.9 / 177.4 s    4 files  146.3 / 147.6 s
20 cores           3 files  156.5 / 147.2 s    4 files  137.8 / 140.5 s

Four is now the default on machines with sixteen or more logical cores, which
includes yours. Nothing to switch on.

Both changes together took a batch here from 220 s to 147 s. Your numbers will
differ — your card is smaller and your processor has 20 cores against 32 — but
the queue that was costing you 160 seconds of every batch is not there any
more. The output is unchanged: byte-for-byte the same files, checked on all
thirteen.

Also in this release

The decoder was clipping anything above full scale on the way in: MP3, AAC,
Vorbis and float WAV, never FLAC or any other integer format. Your sources are
FLAC, so nothing about your conversions changes; if you ever convert lossy
files, that is now fixed.

What would help

The same 14-file test at 30M, and at 10M if you have the patience, with the
log. Two things I would like to see in it: the new line at the start of a
batch that reads [GPU/VRAM] admission budget … MB, and whether taking turns with the other worker appears anywhere at all. If it does, I have the budget
wrong for your card and want to know.

And if you feel like one more experiment: from a Command Prompt in the app's
folder,

set AURA_GPU_WORKERS=5
aura-engine.exe

runs five files at once. Four is where it stopped paying here; whether that
holds on 20 cores I genuinely do not know.

[Gramofonik]

1 -14 AURA_GPU_WORKERS=5 - 25.64x
14 -1 AURA_GPU_WORKERS=5 - 28.38x

2 x (1x 7-1 + 1 x 8-14) AURA_GPU_WORKERS=5 - 26.72x

Fastest
2 x (1x 7-1 + 1 x 8-14) AURA_GPU_WORKERS=4 - 36.54x

[ToxaDev]

Sorry for the long silence, and thank you. You ran exactly the test I asked for, the same evening, with both logs, and it deserved an answer that week.

What your 1.2.9 logs show

The budget reads right on your card: admission budget 5178 MB — 6904 MB free on the card's 7891 MB. "Taking turns" doesn't appear once in either log, nothing waited for system memory, and nothing fell back to the processor. So the queue for the card, 160 seconds of waiting per batch in your 32 GB runs, is gone, as it should be.

They also show what limits you now. Your runs were at FS×4, so they don't compare with the FS×8 figures from the 15th, but they compare with each other: the same 14 files took 118.6 s at 30M and 115.2 s at 10M. A filter three times shorter saved three seconds, so the card no longer sets your time; the processor-side stages do. Your other numbers fit that: a fifth worker in one copy made little difference, 25.6–28.4× depending on the order, against 26.8× with four in your 30M log.

Two copies with four workers each, at 36.5×, is the interesting one. It means a single copy leaves part of the machine idle, and I don't know yet which part.

What 1.5.1 changes for you

https://github.com/ToxaDev/aura-engine/releases/tag/v1.5.1

• No more timing batches by hand. When a batch ends, the Convert all button shows the audio time and how many times real time it ran, and each file's row shows its own figure beside its ✓. Hover over the button for the time the whole batch took and each file's own time (the first twelve files there; the session log has every one).
• The convolution keeps half of each spectrum: a 30M ×8 filter needs 416 MB on the card instead of 736. On an RTX 4090 that makes a 30M ×8 conversion up to 1.4× faster. Since the card isn't your limit any more, don't expect that much.
• A long file now reserves the card for its whole filter set before it starts, so two long files can't end up on an 8 GB card together, and it checks for room for its temporary files first.
• One copy at a time. 1.5.1 has a player, and the player needs the output device to itself, so starting a second copy brings the first window forward instead. Your two-copy setup won't run with it. Getting one copy as fast as two is in the works.

What isn't in it

The blend I described on 11 September, mixing the two Hybrid-Phase renders piece by piece instead of holding both in memory, isn't in 1.5.1. Your 32 GB test made the waiting disappear on your machine, and the card queue behind it was the bigger loss, so that went first. On 16 GB machines the blend would still matter, and it's still in the works.

[Gramofonik]

[AE · 44.1k→176.4k · Kaiser 30M · f64 · SUB20 · AA · HP]
session-2026-09-16_21-21-19.log

log

[Gramofonik]

[AE · 44.1k→176.4k · Kaiser 10M · f64 · SUB20 · AA · HP]
Speed: 27.88x
session-2026-09-16_22-05-59.log