DecayCore — Free FIR room correction with temporal decay control, automatic optimization and measurement workflow

[Kali-]

what about an arm64 version for Raspberry Pi ?
i'm the one who time ago asked for a MacOS intel, i know i can use the source code version, but with it i can use only measurement from REW and i like to try the one made by DecayCore (as recommended) which is only available on official release, and i miss all supported OS

 

[VilhoValittu]

what about an arm64 version for Raspberry Pi ?
i'm the one who time ago asked for a MacOS intel, i know i can use the source code version, but with it i can use only measurement from REW and i like to try the one made by DecayCore (as recommended) which is only available on official release, and i miss all supported OS

Hi,

I have old Raspi 3b. I can compile program for you at somepoint at near future.
It seems that GitHub Actions can build that for 64-bit systems. Pi 4/5 etc.

I just found bug at guided multi-take measurement. Some mic&os compinations caused hf drop. I deal that first.

v1.1.1 inc arm64 linux version

 

[landco1]

I just found bug at guided multi-take measurement

So I didn't dream

 

[VilhoValittu]

Small DecayCore update: v1.1.2 is out.

The main thing in this one is phase correction. I spent a lot of time sanding, trimming, re-checking, and generally refusing to leave it alone until it behaved properly. So this is not a “more phase, more better” release. It is a “phase correction is now much more dialed in, controlled, and better mannered” release. Less drama, less weirdness, more confidence that it does what it should without trying to become the main character above the Schroeder region.

There are also some smaller polish improvements around the edges, but the headline is definitely that the phase side has had a proper cleanup and fine-tuning pass.
In other words: phase correction now properly joins the party, and fortunately it brought audible improvements instead of just new ways to ruin a graph.

v1.1.2

 

[john61ct]

which modes are affected, Mixed Phase and Minimum Phase as well?

Are DRC and crossovers correction separated at all in the workflow?

DecayCore — Free FIR room correction with temporal decay control, automatic optimization and measurement workflow

I am personally working on, planning for a multi-sub system that will be "somewhat portable", sometimes used outdoors. So room correction needs to be kept a separate "layer" from the crossovers "speaker building" / bass management side. Even maybe doing the timing / spatial tuning, smoothing...

www.audiosciencereview.com

 

[digitalfrost]

The default settings now work really well for me.

 

[VilhoValittu]

which modes are affected, Mixed Phase and Minimum Phase as well?

Are DRC and crossovers correction separated at all in the workflow?

DecayCore — Free FIR room correction with temporal decay control, automatic optimization and measurement workflow

I am personally working on, planning for a multi-sub system that will be "somewhat portable", sometimes used outdoors. So room correction needs to be kept a separate "layer" from the crossovers "speaker building" / bass management side. Even maybe doing the timing / spatial tuning, smoothing...

www.audiosciencereview.com

Mostly Mixed Phase, and also the modes where phase correction is actually part of the game, so Linear/Asymmetric too. Minimum Phase is much less affected, since it is not trying to do the same excess-phase cleanup in the first place.

As for workflow separation: yes, reasonably so. The main DRC is one layer, and crossover / bass integration is another layer when enabled, with its own timing, polarity, gain, and HPF/LPF handling. So not completely separate universes, but also not one giant DSP spaghetti incident.

 

[VilhoValittu]

The default settings now work really for me.

Nice to hear.

 

[john61ct]

Mostly Mixed Phase, and also the modes where phase correction is actually part of the game, so Linear/Asymmetric too. Minimum Phase is much less affected, since it is not trying to do the same excess-phase cleanup in the first place.

As for workflow separation: yes, reasonably so. The main DRC is one layer, and crossover / bass integration is another layer when enabled, with its own timing, polarity, gain, and HPF/LPF handling. So not completely separate universes, but also not one giant DSP spaghetti incident.

sounds excellent! Thanks for all your work for the community

 

[landco1]

sounds excellent!

You are in a hurry to draw conclusions. Much more time is needed for qualitative analysis

 

[Vl_Po]

I don't have an urgent need to use correction, because 99% of the time I use iem to listen to music.
However, I'm interested in the topic itself. I have at my disposal a simple computer speaker on which I am trying to conduct "experiments". And to DecayCore's credit, I can say that even with such initial data, it was able to measure and calculate the correction (for comparison, the GSonic Reference basically cannot make measurements on my Arch Linux due to the terrible distortions of the test signal).
@VilhoValittu , thank you for the program and your hard work!

 

[VilhoValittu]

I don't have an urgent need to use correction, because 99% of the time I use iem to listen to music.
However, I'm interested in the topic itself. I have at my disposal a simple computer speaker on which I am trying to conduct "experiments". And to DecayCore's credit, I can say that even with such initial data, it was able to measure and calculate the correction (for comparison, the GSonic Reference basically cannot make measurements on my Arch Linux due to the terrible distortions of the test signal).
@VilhoValittu , thank you for the program and your hard work!

That's interesting to hear. I'm curious to see final outcome what DecayCore did.

 

[Vl_Po]

That's interesting to hear. I'm curious to see final outcome what DecayCore did.

So far, I have only confirmed that the program is working properly I'll take more accurate measurements later, and then I can show you something.

 

[john61ct]

You are in a hurry to draw conclusions. Much more time is needed for qualitative analysis

My comment was simply expressing a noob's perception of the dev's intent, meant to be encouraging.

Yours sounds negative and nitpicky.

 

[VilhoValittu]

My comment was simply expressing a noob's perception of the dev's intent, meant to be encouraging.

Yours sounds negative and nitpicky.

Fair point that proper qualitative analysis takes time.


But I read “sounds excellent” as encouragement, not as a final verdict carved into stone tablets.


Early positive reactions and deeper critical analysis are both useful. The main thing is keeping the feedback constructive, especially for free community tools.

 

[landco1]

Fair point that proper qualitative analysis takes time.

I found a flaw in the Linux version of DecayCore: the program only sees real (ALSA hardware) devices and does not see software audio devices - virtual DSP cards, for example.
This prevents you from working with the program fully.

 

[john61ct]

Doesn't PipeWire allow for the routing flexibity you need?

and/or JACK, apparently they work well together.

What other Linux interfaces are there these days?
that aren't limited to desktop audio / stereo...

 

[Kali-]

I found a flaw in the Linux version of DecayCore: the program only sees real (ALSA hardware) devices and does not see software audio devices - virtual DSP cards, for example.
This prevents you from working with the program fully.

View attachment 538808

are you sure?, i have added a simple pcm device and it's listed
i think the progam load it at startup and can't refresh

~/.asoundrc
pcm.alc283_48k {
type plug

slave {
pcm "hw:0,0"
rate 48000
channels 2
format S16_LE
}
}

 

[landco1]

are you sure?, i have added a simple pcm device and it's listed
i think the progam load it at startup and can't refresh

~/.asoundrc
pcm.alc283_48k {
type plug

slave {
pcm "hw:0,0"
rate 48000
channels 2
format S16_LE
}
}

The problem is for DecayCore to see the virtual 2.1 sound card as a whole – both in stereo mode and when measuring the subwoofer channel.

 

[john61ct]

I thought the ALSA driver presents the channels individually - no such thing as access to "a card" in Linux

I may be wrong