2018 - BrutefirDRC still works :-)

[Archimago X]

Hey guys, I know this group is very much silent since the development of the software has ceased for years!

Just want to remind folks that this still works very well for room correction purposes with LMS. This week, I just updated to 64-bit Ubuntu 18.04.1 LTS in Oracle VirtualBox. BrutefirDrc still working like a champ once you get everything working :-).

I wrote a piece detailing my set-up procedure awhile back with some updates:

https://archimago.blogspot.com/2016/03/howto-logitech-media-server-brutefirdrc.html

Hope this helps some folks out...

Arch

[franc...@comcast.net]

I wrote a piece detailing my set-up procedure awhile back with some updates:

https://archimago.blogspot.com/2016/03/howto-logitech-media-server-brutefirdrc.html

Hope this helps some folks out...

Arch

Thanks for this informative set-up procedure.  I have set up LMS on a RPi 3B+ and it is working well with a large USB drive.  The motivating goal has been to implement BrutefirDrc in the LMS feed.  I am not sure it is working, though I see no specific errors in the log file.  The filter configuration files, when tested separately with brutefir on the command line, do not cause errors and 'filtering begins now'.  This spawns multiple processes, visible via 'top'.  However, when LMS is running I can see no instance of brutefir processes using 'htop'.  Even though *I think* I hear the results of the filters in the music stream, it would be nice to confirm that brutefirDRC is running correctly!  CPU usage is suspiciously light - about 5% on one core @ 44.1kHz.  I am using a recent LMS nightly of 7.9.2, and am using filters generated in rePhase.  I have tried both LPCM.wav and text formats for the filters within the bruteFIR configuration files.  ...same behavior for each.

Any suggestions would be greatly appreciated!  Thanks in advance!

Frank

[dav...@gmail.com]

On Friday, February 15, 2019 at 3:17:24 PM UTC-8, franc...@comcast.net wrote:

Thanks for this informative set-up procedure.  I have set up LMS on a RPi 3B+ and it is working well with a large USB drive.  The motivating goal has been to implement BrutefirDrc in the LMS feed.  I am not sure it is working, though I see no specific errors in the log file.  The filter configuration files, when tested separately with brutefir on the command line, do not cause errors and 'filtering begins now'.  This spawns multiple processes, visible via 'top'.  However, when LMS is running I can see no instance of brutefir processes using 'htop'.  Even though *I think* I hear the results of the filters in the music stream, it would be nice to confirm that brutefirDRC is running correctly!  CPU usage is suspiciously light - about 5% on one core @ 44.1kHz.  I am using a recent LMS nightly of 7.9.2, and am using filters generated in rePhase.  I have tried both LPCM.wav and text formats for the filters within the bruteFIR configuration files.  ...same behavior for each.

Any suggestions would be greatly appreciated!  Thanks in advance!

If you can see brutefir in top, I'd say it's working.  I would also check that the link in /etc/squeezebox/BrutefirDrc/settings is not broken and is pointing to the right filter:

$ ls -l /etc/squeezeboxserver/BrutefirDrc/settings

I use REW to test the frequency response of my filters.  You can generate measurement sweeps with timing reference chirps with REW and save them on the music server for playback.  When you start the measurement in REW, wait until it says "Waiting for timing reference..." and then play the sweep from the server.  Alternatively you can install Shairplay on LMS and play measurment sweeps directly from REW using airplay, though I've had problems with pops and clicks in the output using this.

BTW, I'm using DRC-FIR to create my filters, with excellent results:

http://drc-fir.sourceforge.net/

I'd like to try rePhase next, and maybe Acourate if I can bring myself to plunk down the cash.

[franc...@comcast.net]

Thanks for this information.  I still suspect that BruteFIR is not running in LMS even though the filters will initialize and run from the command line.

Could the filter permissions/ownership be an issue?  What should the permissions be and who should own them?  At present, LMS is running and I'm seeing this:

pi@raspberrypi:/ $ ls -l /etc/squeezeboxserver/BrutefirDrc/settings

total 28

-rwxr--r-- 1 root             root    2763 Feb 16 00:18 DRC-176400.txt

-rwxr--r-- 1 root             root    2763 Feb 16 00:18 DRC-192000.txt

-rwxr--r-- 1 root             root    2768 Feb 16 16:55 DRC-44100.txt

-rwxr--r-- 1 root             root    2760 Feb 16 00:18 DRC-48000.txt

-rwxr--r-- 1 root             root    2760 Feb 16 00:18 DRC-88200.txt

-rwxr--r-- 1 root             root    2759 Feb 16 00:18 DRC-96000.txt

lrwxrwxrwx 1 squeezeboxserver nogroup   13 Feb 15 23:27 filter-6c_ec_eb_67_6f_9f -> DRC-44100.txt

-rw-r--r-- 1 squeezeboxserver nogroup 3330 Mar  5 08:30 wisdom

I imagine that root is a problem, so I've tried other possibilities...

TIA,

Frank

[Dave Cook]

All files should have user "squeezeboxserver" and group "nogroup".

On Ubuntu server I had set permissions on /tmp to 777, but perhaps there's a less crude way to do this.

Dave Cook

--
You received this message because you are subscribed to the Google Groups "BrutefirDRC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brutefirdrc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[franc...@comcast.net]

Again, thanks for the help.  I made everything 777 and adjusted ownership:group with chown -R to the entire folder /BrutefirDrc.  Still no indication that BruteFIR is running:

  pi@raspberrypi:/ $ ps xa | grep brutefir

  771 pts/0    S+     0:00 grep --color=auto brute fir

In all other respects LMS seems to be working normally so I suspect my own understanding and not Raspbian, or some technical/system issue.

I do see something I don't understand on the LMS plugin configuration page under the 'advanced' tab for BturefirDrc.  For the 'BruteFIR filter link directory'  I have "/etc/squeezeboxserver/BrutefirDrc/settings".  (correct directory, I hope!)  OK, there is a small information pop-up associated with that input and the popup says:  

"The absolute path to the directory where the filters configured for each player can be saved to. It is the plugins working directory. If a filter is changed for a player a file for the player referencing the new filter will be created in this directory. Make sure that the directory exists and is writeable by the SqueezeCenter user. Files in this directory are overwritten without warning! If you want to be absolutely safe create a directory only for this purpose. If this directory is changed you have to enable DRC again for any player via the remote control (yes it states that it is enabled you have to do it nevertheless, after enabling it you need to restart SqueezeCenter)."

That folder (.../BrutefirDrc/settings) is now at 777.  But what is the process of 'enabling DRC via the remote control'?  What/where is this 'remote control' the popup is referencing?  I'm playing LMS output through squeezelite 1.8 on a BBB with LMS control using either a) http to the :9000 port at my players IP address, or b) the iOS program iPeng.  Using the :9000 port I see two things to 'enable':  a) BrutefirDrc is checked in the 'active plugins' group under the 'plugins' tab, and b) under the tab 'Player->Squeezelite->Brutefir room correction' I see Template = FLAC and Filter = DRC-44100.txt.  These are the only controls I know about to 'enable DRC'.  If there is another control interface somewhere, that would be good to know about!  ;-P

I'm hoping my problem is something almost silly.  But like all software problems, trivial and profound problems are equally important until the program works!

TIA, again!

Frank

[Dave Cook]

Check that the link in in /etc/sqeezeboxserver/BrutefirDrc/settings is not broken (simple way is to try to cat the link).  I've seen a problem where the link will not be set properly the first time, and I have to try several times before the link is actually pointing the right file.

Dave  

[franc...@comcast.net]

I found the answer almost by mistake:  https://soundcheck-audio.blogspot.com/2017/08/logitechmediaserver-settings-guide.html

I had no idea that so much was going on behind the scenes, and that you had to disable file conversion pathways to make the BruteFIR wrapper the default for FLACs.  Also, I didn't realize that you can't convert some file types to FLAC and then have them sent to the BruteFIR wrapper.  So, now I've seen the wrapper kick-in and then, yes, the processes for BruteFIR show up in Linux under 'htop' or 'ps'.  The plugin was working all along, but it was not the first choice within the LMS chain.  I think a custom conversion setup for LMS might be in order (after a bunch of other things get done), and for now it seems that FIR filtering may not be universally applicable to anything LMS will be asked to play.

Thoughts or comments?

Cheers,

Frank

[Dave Cook]

On Thu, Mar 21, 2019 at 10:53 PM <franc...@comcast.net> wrote:

I had no idea that so much was going on behind the scenes, and that you had to disable file conversion pathways to make the BruteFIR wrapper the default for FLACs.  Also, I didn't realize that you can't convert some file types to FLAC and then have them sent to the BruteFIR wrapper.  

The only kind of FLAC that I can think of that wouldn't work at all would be DSD-over-PCM (DoP) files.  I could  not figure out how to turn these directly into "real" PCM FLACs (other than starting with the original DSD ISO or DSF files).

Also, any FLAC with a sample rate without a corresponding filter will not play back when BruteFirDRC is enabled.   

I haven't gotten into the custom conversion.  It seems sensible to downsample anything over 96 kHz before filtering rather than create filters for it, and I believe that would need a custom conversion file.

Dave Cook