Digital Room Correction and Bass Artefacts

[cliveb]

Having set up DRC using a RPi with HiFiBerry DIGI2 Pro + DSP card, I have an issue.

When setting it up (having used REW to calculate the required filters), I was of course using source material with significant bass content to audition the results, and pleased with the way it tamed the bass humps in the room.

But once I started listening in earnest, noticed some curious low frequency artefacts during quiet moments, a kind of grumbling that varies in amplitude. The closest analogy I can give is that it sounds a bit like turntable rumble. Thinking I might be imagining it, I tried playing something while toggling the filters on & off, and the artefacts are definitely only present when the filters are active. It's quite subtle and only at very low frequencies. I can't hear it on (admittedly inexpensive) headphones, only on my active Meridian speakers.

The filters are fairly extreme, with some significant gain settings and high Q:

Filter  1: ON  PK       Fc    54.3 Hz  Gain -19.2 dB  Q 2.831
Filter  2: ON  PK       Fc    71.1 Hz  Gain   9.0 dB  Q 3.982
Filter  3: ON  PK       Fc    75.2 Hz  Gain  -5.4 dB  Q 7.677
Filter  4: ON  PK       Fc    89.3 Hz  Gain  -5.5 dB  Q 11.271
Filter  5: ON  PK       Fc     148 Hz  Gain -13.3 dB  Q 13.429
Filter  6: ON  PK       Fc     202 Hz  Gain  -6.2 dB  Q 5.000
Filter  7: ON  PK       Fc     225 Hz  Gain   6.3 dB  Q 5.000

My question for the experts here is whether these kind of grumbling low frequency artefacts are a known issue with DRC.
Perhaps they are to be expected with such extreme filtering?
Maybe the code that HiFiBerry uses to implement the filters isn't as good as it ought to be?

I'm in a bit of a quandary: with the filters turned on, the bass response is nice and smooth, but now I've heard those artefacts, they are impossible to ignore. With the filters turned off, the bass has some pretty obvious humps that I would like tamed.

[foxesden]

Hi,

Most of your filters are attenuating the bass but filter 2

Filter 2: ON PK Fc 71.1 Hz Gain 9.0 dB Q 3.982

is adding a lot of gain in between filter 1 and 3 which are attenuating bass.

Filter 1: ON PK Fc 54.3 Hz Gain -19.2 dB Q 2.831
Filter 2: ON PK Fc 71.1 Hz Gain 9.0 dB Q 3.982
Filter 3: ON PK Fc 75.2 Hz Gain -5.4 dB Q 7.677

So is the intention to boost this frequency. If it is then it will only target very specific frequency and possibly give a weird effect. I would suggest lowering this value and see if it gets rid of the artefacts.

[cliveb]

Hi,

Most of your filters are attenuating the bass but filter 2

Filter 2: ON PK Fc 71.1 Hz Gain 9.0 dB Q 3.982

is adding a lot of gain in between filter 1 and 3 which are attenuating bass.

Filter 1: ON PK Fc 54.3 Hz Gain -19.2 dB Q 2.831
Filter 2: ON PK Fc 71.1 Hz Gain 9.0 dB Q 3.982
Filter 3: ON PK Fc 75.2 Hz Gain -5.4 dB Q 7.677

So is the intention to boost this frequency. If it is then it will only target very specific frequency and possibly give a weird effect. I would suggest lowering this value and see if it gets rid of the artefacts.

All these filter settings were what REW calculated based on the room measurement, so that's how I set them up.
But I agree that they are a bit weird. 9dB of gain just 4Hz away from 5.4dB of cut does seem pretty strange.

I have tried removing filter 2 and slightly reducing the amount of attenuation on the neighbouring filters - we'll see how that goes.

I'm beginning to wonder if I'm in danger of getting trapped in a cycle of fiddling around trying to find the best compromise. Having to keep swapping between HiFiBerryOS to set up the filters and piCorePlayer to properly audition the results is a pain in the rear. Just listening to music would be a better use of my time.

At the moment, the low level bass grumbling caused by the DSP room correction is more annoying than the lumpy response of the room. Wouldn't surprise me if I end up removing the DSP card completely and just accepting the bass nodes in the room!

[BoxOfCables]

I'm beginning to wonder if I'm in danger of getting trapped in a cycle of fiddling around trying to find the best compromise. Having to keep swapping between HiFiBerryOS to set up the filters and piCorePlayer to properly audition the results is a pain in the rear. Just listening to music would be a better use of my time.

Like you I started out with a Hifiberry DSP using REW, I didn't get any bass issues like you have, but the board and the dsptoolkit were very unreliable. I did spend more time fixing issues than listening to music. The board recently died, and I've discovered that it's pretty simple to implement the filters through SoX which can be done with a file upload through piCorePlayer web interface. Even a lowly pi3B can cope with running the filters without issue.

[cliveb]

... I've discovered that it's pretty simple to implement the filters through SoX which can be done with a file upload through piCorePlayer web interface. Even a lowly pi3B can cope with running the filters without issue.

Do you have any links to guidance for doing this?
I'd always assumed that my Pi3 LMS server wouldn't have the necessary grunt to run DRC filters, but now you've reassured me I'd like to give it a try.

[BoxOfCables]

Do you have any links to guidance for doing this?
I'd always assumed that my Pi3 LMS server wouldn't have the necessary grunt to run DRC filters, but now you've reassured me I'd like to give it a try.

You need to create a text file (you can use Notepad etc.) containing the something like the following (this will become "custom-convert.conf" on the server):

flc flc * *
	[sox] -q --multi-threaded --no-clobber -t flac $FILE$ -t flac - equalizer 99.6 2.70q +3.6 equalizer 283 1.00q -2.9 equalizer 2293 1.00q +1.4

Each entry for "equaliser" can hold one filter from REW. The first value is the Hz, the second number is the quantisation (Q) and the third is the gain (positive or negative). This one has three filters, it applies only to flac files. You would need additional blocks for different formats.

In REW, using a generic equaliser will give you a filters file like below (this is not the one to match the convert above, don't get confused ). You can see it has the Hz, gain and Q. So all you need to do is pick those out and write them into the "custom-convert.conf" format.

Filter Settings file

Room EQ V5.19
Dated: 21-Dec-2018 15:23:09

Notes:

Equaliser: Generic
Dec 21 15:06:19
Filter  1: ON  PK       Fc    29.9 Hz  Gain  -2.8 dB  Q 6.589
Filter  2: ON  PK       Fc    38.7 Hz  Gain  -2.3 dB  Q 3.502
Filter  3: ON  PK       Fc    63.3 Hz  Gain  -2.7 dB  Q 2.000
Filter  4: ON  PK       Fc    80.4 Hz  Gain  -2.4 dB  Q 36.106
Filter  5: ON  PK       Fc     120 Hz  Gain  -7.5 dB  Q 3.864
Filter  6: ON  PK       Fc     122 Hz  Gain   9.0 dB  Q 12.341
Filter  7: ON  PK       Fc     142 Hz  Gain  -8.6 dB  Q 33.829
Filter  8: ON  PK       Fc     145 Hz  Gain -11.2 dB  Q 25.092
Filter  9: ON  PK       Fc     147 Hz  Gain   9.0 dB  Q 5.743
Filter 10: ON  PK       Fc     172 Hz  Gain -10.2 dB  Q 10.848
Filter 11: ON  PK       Fc     183 Hz  Gain   7.0 dB  Q 28.041
Filter 12: ON  PK       Fc     221 Hz  Gain  -5.1 dB  Q 4.909
Filter 13: ON  PK       Fc     280 Hz  Gain   9.0 dB  Q 5.000
Filter 14: ON  PK       Fc     297 Hz  Gain -17.8 dB  Q 5.000
Filter 15: ON  PK       Fc     315 Hz  Gain   5.6 dB  Q 5.000
Filter 16: ON  PK       Fc     405 Hz  Gain  -3.3 dB  Q 5.000
Filter 17: ON  PK       Fc     415 Hz  Gain   9.0 dB  Q 3.357
Filter 18: ON  PK       Fc     481 Hz  Gain  -3.1 dB  Q 1.000
Filter 19: ON  PK       Fc     950 Hz  Gain  -2.2 dB  Q 5.000
Filter 20: ON  PK       Fc    1192 Hz  Gain  -5.8 dB  Q 5.000

Once you have your text file ready with the filter values, head to the piCorePlayer web interface, click the "LMS" tab and upload your file using this input:



Select the file, then hit upload and it will whirr away for a bit and restart LMS, and you'll have your filters applied. If you want to undo them, simply upload a blank document.

[cliveb]

You need to create a text file (you can use Notepad etc.) containing the something like the following (this will become "custom-convert.conf" on the server):
[snip]

Excellent - many thanks. That all looks very straighforward, and I already have the REW filter settings.

It will interesting to see if the filters used by SOX produce bass artefacts like those on the HiFiBerry DSP card.
If they don't, the DSP card will be going on eBay!

EDIT: Given that I want to target the specific piCorePlayer in my living room, I presume I need to set up custom-convert like so:

flc flc * PLAYER-ID
	[sox] ...

where PLAYER-ID is the MAC address or IP address of the target piCorePlayer?

[BoxOfCables]

Excellent - many thanks. That all looks very straighforward, and I already have the REW filter settings.

It will interesting to see if the filters used by SOX produce bass artefacts like those on the HiFiBerry DSP card.
If they don't, the DSP card will be going on eBay!

EDIT: Given that I want to target the specific piCorePlayer in my living room, I presume I need to set up custom-convert like so:

flc flc * PLAYER-ID
	[sox] ...

where PLAYER-ID is the MAC address or IP address of the target piCorePlayer?

Yes, it should just be the MAC address.

If you want an easy way to see if it's working, use the following which will turn off the right channel [EDIT - the remix command was wrong, removed the "-m" from it]:

flc flc * *
	[sox] -q --no-clobber -t flac $FILE$ -t flac - remix 1 0

It does add to the load on the Pi, but it's not much (about 6% cpu load running, 26% starting the track) - the initial start time to play a track is a little longer (still under 2 seconds from my testing with about 5 filters and a remix to alter the balance).

[BoxOfCables]

In case anyone was trying the above, I've now edited it as the command for turning off one channel was wrong.

I've also done some more tweaking and found limiting the flac compression level to zero helps a lot with the initial delay, it's now pretty much imperceptable. Here's the conf:

flc flc * *
	[sox] -q --multi-threaded --no-clobber -t flac $FILE$ -C 0 -t flac - equalizer 99.6 2.70q +3.6 equalizer 283 1.00q -2.9 equalizer 2293 1.00q +1.4

If you need to alter the balance L/R but don't have such a control on the amplifier, that can be done too (using the remix command):

flc flc * *
	[sox] -q --multi-threaded --no-clobber -t flac $FILE$ -C 0 -t flac - equalizer 99.6 2.70q +3.6 equalizer 283 1.00q -2.9 equalizer 2293 1.00q +1.4 remix -m 1p-3 2p0

The value after the "p" is the db by which to alter that channel. I believe it's best to reduce than increase as there's no chance of clipping then. The example above reduces the left channel by 3db.

[cliveb]

I've also done some more tweaking and found limiting the flac compression level to zero helps a lot with the initial delay, it's now pretty much imperceptable.

Thanks again.

Would it reduce any delay even further by not re-encoding to FLAC, and just stream the output as PCM? My understanding is that FLAC decodes really easily but uses quite a lot of CPU to encode. Not bothering to re-encode might also reduce the load on the RPi3. All my players are connected via gigabit wired ethernet, so I don't need to worry about network bandwidth.

[cliveb]

OK, have hit a problem.

I created a simple custom convert file using Notepad just to test that it works, but got this error message when attempting to upload it:

[ERROR] Invalid file format, must be a text file"

Thinking perhaps it might be due to Windows using CR/LF for newline, I removed the CR characters using a hex editor and tried again, but with the same result.

Any ideas?

Here is the full content of the file I was trying to upload:

flc flc * *
	[sox] -q --multi-threaded --no-clobber -t flac $FILE$ -t flac - remix 1 0

Are there any header lines I need to include? (The "invalid file format" messsage would seem to suggest it's nothing to do with the content, but a more fundamental issue).

I'm using an old pCP (v4.1.0), if that's relevant. Was hoping not to have to upgrade, but will if it's required.

[BoxOfCables]

got this error message when attempting to upload it:

Sorry I don't know why that would be - I've tested here (using Notepad) and I can upload a "something.txt" or "something.conf" file and it works fine, even with [CR][LF] line endings. I even tried a few odd tabs / whitespaces and it accepted it. I am on the latest pCP though. The file contents as you posted here are fine, there isn't anything that would need changing or adding.

You could try directly uploading it, rather than updating pCP as a first course of action. Name the file "custom-convert.conf" and put it in "/usr/local/slimserver" (it doesn't need any special permissions). Then restart LMS and see.

Would it reduce any delay even further by not re-encoding to FLAC, and just stream the output as PCM?

From what I understand, it has to output flac to match the rule (the second entry in the first line is the output format requested by the player). If your players are configured to request PCM then you can alter the SoX command to change it to output PCM, and also change the matching for the rule from "flac flac" to "flac pcm". I've not read the SoX documentation for PCM, a breif look shows a few more options than flac so you'd need to pick your way through that.

[cliveb]

You could try directly uploading it, rather than updating pCP as a first course of action. Name the file "custom-convert.conf" and put it in "/usr/local/slimserver" (it doesn't need any special permissions). Then restart LMS and see.

OK, I gave that a go and it worked.
So now I'll try applying the filters to see what happens, and if that works will experiment with not bothering to re-encode to FLAC and just stream PCM.

Many thanks for your help.

[cliveb]

OK, latest news on this.

I set up the appropriate equalizer settings in custom-convert.conf and am happy to report that:

1. They work - the bass response is smoothed out as required. Not quite perfect yet, but I can try a bit of fine tuning.

2. Re-encoding to FLAC works just fine. The peak CPU usage on the RPi3 I've seen is about 25%, and that is only during the initial phase when playback is starting up. Once it's going, CPU usage typically sits around the 3% - 5% mark. With re-encode compression level set to 0, there is no significant latency. So I probably won't bother messing about trying to stream PCM.

3. Most importantly of all: there are no audible bass artefacts. Hooray!
It would seem that the filtering code used by the HiFiBerry DSP card must have some kind of flaw which is responsible.
I did wonder if perhaps the card itself had a hardware fault, but when the card is installed and all filters disabled, the bass artefacts disappear.
So it has to be something to do with the filter processing.

Anyway, all is now well without the DSP card installed and I'm a happy bunny.

[BoxOfCables]

Anyway, all is now well without the DSP card installed and I'm a happy bunny.

Awesome Glad it all worked for you. I wish I had known about SoX before I wasted £70 and who knows how many hours on that HiFiBerry DSP! On the plus side though it did introduce me to REW which makes a nice improvement to the sound.

The peak CPU usage on the RPi3 I've seen is about 25%

Same as I've seen, that's actually 100% load on a single core. The multi-threading on SoX doesn't seem to work on the Pi, I had expected to see it jump to 50% use, using one core per audio channel. Still, it's not a noticeable delay with that lowest compression.

Happy listening!