• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required as is 20 years of participation in forums (not all true). Come here to have fun, be ready to be teased and not take online life too seriously. We now measure and review equipment for free! Click here for details.

Volumio & BruteFIR related discussion

somebodyelse

Active Member
Joined
Dec 5, 2018
Messages
221
Likes
154
#2
To get BruteFIR to load a wav file as a filter you need to specify both the format and the 'skip' offset to get past the header. The wav header is a fixed 44 bytes, so for my 24 bit mono wav I needed to set:
Code:
format: "S24_LE";
skip: 44;
BruteFIR now loads without errors, and music plays.
To be generally applicable the wav header needs parsing to find the format and check that it's the right number of channels. I don't know if there are any gotchas like differing subformats of 24 bit.
 

Krunok

Major Contributor
Joined
Mar 25, 2018
Messages
3,844
Likes
1,977
Location
Zg, Cro
#3
To get BruteFIR to load a wav file as a filter you need to specify both the format and the 'skip' offset to get past the header. The wav header is a fixed 44 bytes, so for my 24 bit mono wav I needed to set:
Code:
format: "S24_LE";
skip: 44;
BruteFIR now loads without errors, and music plays.
To be generally applicable the wav header needs parsing to find the format and check that it's the right number of channels. I don't know if there are any gotchas like differing subformats of 24 bit.
Nice, thank you for the info!

These filter formats are suported by rePhase:



When working as a tester with developer who ported BruteFIR as a Volumio plugin I first got text format to work so we sticked with that as we thought this was the most common format. I can also confirm that

format: "FLOAT64_LE"; works with dbl filters created with rePhase.

Speaking of that, do you see any advantage in using PORC over rePhase or you are only reluctant to learn to work with new tool when you're accustomed to the old one? :)
 
Last edited:

somebodyelse

Active Member
Joined
Dec 5, 2018
Messages
221
Likes
154
#4
I just noticed BruteFIR will also start without errors with the text files and the binary config definition, presumably with unexpected results.

I haven't tried DRC before, so I'm not accustomed to any tools. The other thread was a good excuse to give it a try. I don't have Windows, so initially skipped over rePhase when looking for something that would generate any config that would work, initially in daphile, to generate a representative load and see if it was glitch free. PORC ran easily and didn't have many options to confuse a newbie, and made configs that worked in daphile. I also had a quick look at drc-fir but haven't tried using it. I've since downloaded rePhase and it at least starts up under wine, so I may now put more effort into producing a decent config.

From what I've read about the issues with BruteFIR and USB it seems to affect most but not all ARM boards, and a small subset of x86, but nobody's nailed down the exact cause. The suspicion seems to be something in the usb2 subsystem that causes delays in responding under certain workloads.

If I end up using DRC I'm unlikely to use either daphile or volumio as I've a homebrew combination of mythtv and squeezelite doing video and audio stuff. What I'm learning looking at it in volumio will help me add BruteFIR or another convolver to my audio config if I decide to go down that route. If it helps improve the brutefir3 plugin then that's a bonus. I've got a few PiCorePlayer boxes in other rooms, but without a specific listening position drc isn't really applicable.
 

Krunok

Major Contributor
Joined
Mar 25, 2018
Messages
3,844
Likes
1,977
Location
Zg, Cro
#5
I just noticed BruteFIR will also start without errors with the text files and the binary config definition, presumably with unexpected results.

I haven't tried DRC before, so I'm not accustomed to any tools. The other thread was a good excuse to give it a try. I don't have Windows, so initially skipped over rePhase when looking for something that would generate any config that would work, initially in daphile, to generate a representative load and see if it was glitch free. PORC ran easily and didn't have many options to confuse a newbie, and made configs that worked in daphile. I also had a quick look at drc-fir but haven't tried using it. I've since downloaded rePhase and it at least starts up under wine, so I may now put more effort into producing a decent config.

From what I've read about the issues with BruteFIR and USB it seems to affect most but not all ARM boards, and a small subset of x86, but nobody's nailed down the exact cause. The suspicion seems to be something in the usb2 subsystem that causes delays in responding under certain workloads.

If I end up using DRC I'm unlikely to use either daphile or volumio as I've a homebrew combination of mythtv and squeezelite doing video and audio stuff. What I'm learning looking at it in volumio will help me add BruteFIR or another convolver to my audio config if I decide to go down that route. If it helps improve the brutefir3 plugin then that's a bonus. I've got a few PiCorePlayer boxes in other rooms, but without a specific listening position drc isn't really applicable.
I never heard about Volumio (with or without BruteFIR) popping issues on anything but RPI. It works well on my PC and I know it works well on Odroid C2 platform.

Actually DRC can make better sound even in the scenario without specific listening position. Yes, frequency range up to app 300Hz is very location dependent but with DRC I got flatter response in all locations in my room, not only at LP even in that range. From app 300Hz up the location practically doesn't affect linearity.

The main obstacle I have encountered when trying to do DRC is that you can hardly find a place where the measurement process is explained simply enough yet with enough details to do it properly. Good guidelines for filter creation are even harder to find so I guess that is the reason why most folks who do it use purchased automated tools like Dirac, which in my opinion give you a better sound to some point but not what you could get if you do it properly by yourself.
 

somebodyelse

Active Member
Joined
Dec 5, 2018
Messages
221
Likes
154
#6
I never heard about Volumio (with or without BruteFIR) popping issues on anything but RPI. It works well on my PC and I know it works well on Odroid C2 platform.
I found the upstream bug report I half remembered, listing other platforms affected, and other triggers. There's input in there from Volumio covering what they've tried to fix it. The patch to the kernel softirq handling may fix it - it seems something similar has been affecting usb dvb devices.

Actually DRC can make better sound even in the scenario without specific listening position. Yes, frequency range up to app 300Hz is very location dependent but with DRC I got flatter response in all locations in my room, not only at LP even in that range. From app 300Hz up the location practically doesn't affect linearity.
I see what you mean I think - fixing up uneven speaker response rather than correcting for room response, but it's the same tool set. Given the low quality of the speakers in question they're not high on my priority list, but I might change my mind after more experience. I'm more likely to look at using BruteFIR as an active crossover.

The main obstacle I have encountered when trying to do DRC is that you can hardly find a place where the measurement process is explained simply enough yet with enough details to do it properly. Good guidelines for filter creation are even harder to find so I guess that is the reason why most folks who do it use purchased automated tools like Dirac, which in my opinion give you a better sound to some point but not what you could get if you do it properly by yourself.
I can't argue with that - I've been looking for just such a guide to get started with. I'd like to see explanations of why each bit needs to be done, not just what to do. Having said that I'll probably be just as guilty of not writing such a guide.
 

somebodyelse

Active Member
Joined
Dec 5, 2018
Messages
221
Likes
154
#7
Since I've been editing the config template I gave the special filename "dirac pulse" a try, since the BruteFIR docs say it's a way to get all the computational expense for testing. At 96kHz I do get occasional faint pops with the Forte whch I don't get with the plugin disabled. I could imagine someone selling it as a vinylizing effect. CPU usage was increased, but still low. Time to track down that kernel patch...
 

somebodyelse

Active Member
Joined
Dec 5, 2018
Messages
221
Likes
154
#8
That patch went into the Raspbian 4.14.y kernel branch in August 2018 from the upstream kernel, and would have been in 4.14.64 or 65. The comments note that it's a partial fix for unintended side effects of a change around 4.9. I think Volumio tracks the Raspbian kernel, although it's not entirely clear. In any case the version I downloaded last week is using 4.14.92-v7+ so that patch should be present.
 

somebodyelse

Active Member
Joined
Dec 5, 2018
Messages
221
Likes
154
#9
Following up with Volumio on x86. It didn't finish booting with the nc4000, just dropped out to shell. That may be an issue between the nc4000 bios and the usb3 stick, but volumio's bigger than daphile and won't fit on the smaller, older stick. I tried the same stick on the Aspire One (Atom 230) and all ran smoothly. Forte again, with template edits both to allow it to work and to use special filename "dirac pulse" for load testing. This time 192kHz worked too, 65536 length and S32_LE. Wired network was used and wireless disabled. Again using the L2 HiDef test files to stress it, streaming via DLNA from separate logitechmediaserver instance. Total CPU usage was ~50% this time, with an unexpectedly large portion being chromium running the gui on the screen. No pops this time.

I revisited the raspberry Pi too, and confirmed pops again with the Forte at 96k.
 

Krunok

Major Contributor
Joined
Mar 25, 2018
Messages
3,844
Likes
1,977
Location
Zg, Cro
#10
Since I've been editing the config template I gave the special filename "dirac pulse" a try, since the BruteFIR docs say it's a way to get all the computational expense for testing. At 96kHz I do get occasional faint pops with the Forte whch I don't get with the plugin disabled. I could imagine someone selling it as a vinylizing effect. CPU usage was increased, but still low. Time to track down that kernel patch...
When you select "None" Dirac pulse filter is used.
 

somebodyelse

Active Member
Joined
Dec 5, 2018
Messages
221
Likes
154
#11
Continuing the more detailed discussion about glitches on the Pi and some other boards from the Cheap solutions for music in silence thread as it's a bit OT for there.

The 4.9.2 there is the version of the gcc compiler, not the kernel which is on the 3.14 branch, although the linked github page has a 3.16 branch too for the c2 which matches @graz_lag DietPi version.

The best guess is that the softirq changes introduced in kernel 4.9 cause a delay in handling certain classes of softirq, including the one used in the usb2 subsystem for the audio transfers. The change was intended to stop softirqs hogging the cpu in cases like network denial-of-service attacks, and significantly improved performance in that case, but had the unintended side effect of making some types of time-critical softirq requests more likely to be handled too late. The watchodg subsystem had some changes to deal with this. There was a fair bit of discussion about how to fix the USB2 issues, which were clearly demonstrated by the DVB maintainers as frequently breaking video streams. Eventually a simple change was made in 4.14.64 or 65 to make the issue less severe while they tried to agree on a more complete approach, which seems to have gone quiet.

In the Raspberry Pi bug thread there are reports of some Arm boards working glitch-free on USN while others have a problem. There are also reports of glitches on x86. The consistently glitch-free Arm boards like the Odroid C2 have a common factor in that they all run older kernels.

The newer kernels don't guarantee glitches, but do make them more likely. Pro audio interfaces designed for low latency also make it more likely as they request smaller hunks of audio data more frequently (bInterval = 1 for the audio subsystem in lsusb -v output), reducing the time available to handle the request. High sample rates will make it more likely. Specific programs running at the same time also make it more likely, and BruteFIR is one of them. Others that have been mentioned are gstreamer and node.js. Presumably this is because they add to the softirq load, but I'm not aware of anyone having done tests to show this. The Raspberry Pi having the network sharing the same subsystem as the USB ports and having a relatively slow cpu seems to be a worst case combination.

The audibility of the glitch will depend on how the DAC handles late arrival of data. For me it's been faint popping at random with the FocusRite Forte at 96kHz, but nothing with the UCA-202 at 48kHz.

I'm aiming to test kernels with and without the specific commits that changed the softirq handling to be absolutely sure that that's the cause of the problem. Volumio makes this particularly awkward from what I can see, so I'm trying to get Raspbian set up to glitch when time allows.
 

Krunok

Major Contributor
Joined
Mar 25, 2018
Messages
3,844
Likes
1,977
Location
Zg, Cro
#12
Continuing the more detailed discussion about glitches on the Pi and some other boards from the Cheap solutions for music in silence thread as it's a bit OT for there.

The 4.9.2 there is the version of the gcc compiler, not the kernel which is on the 3.14 branch, although the linked github page has a 3.16 branch too for the c2 which matches @graz_lag DietPi version.

The best guess is that the softirq changes introduced in kernel 4.9 cause a delay in handling certain classes of softirq, including the one used in the usb2 subsystem for the audio transfers. The change was intended to stop softirqs hogging the cpu in cases like network denial-of-service attacks, and significantly improved performance in that case, but had the unintended side effect of making some types of time-critical softirq requests more likely to be handled too late. The watchodg subsystem had some changes to deal with this. There was a fair bit of discussion about how to fix the USB2 issues, which were clearly demonstrated by the DVB maintainers as frequently breaking video streams. Eventually a simple change was made in 4.14.64 or 65 to make the issue less severe while they tried to agree on a more complete approach, which seems to have gone quiet.

In the Raspberry Pi bug thread there are reports of some Arm boards working glitch-free on USN while others have a problem. There are also reports of glitches on x86. The consistently glitch-free Arm boards like the Odroid C2 have a common factor in that they all run older kernels.

The newer kernels don't guarantee glitches, but do make them more likely. Pro audio interfaces designed for low latency also make it more likely as they request smaller hunks of audio data more frequently (bInterval = 1 for the audio subsystem in lsusb -v output), reducing the time available to handle the request. High sample rates will make it more likely. Specific programs running at the same time also make it more likely, and BruteFIR is one of them. Others that have been mentioned are gstreamer and node.js. Presumably this is because they add to the softirq load, but I'm not aware of anyone having done tests to show this. The Raspberry Pi having the network sharing the same subsystem as the USB ports and having a relatively slow cpu seems to be a worst case combination.

The audibility of the glitch will depend on how the DAC handles late arrival of data. For me it's been faint popping at random with the FocusRite Forte at 96kHz, but nothing with the UCA-202 at 48kHz.

I'm aiming to test kernels with and without the specific commits that changed the softirq handling to be absolutely sure that that's the cause of the problem. Volumio makes this particularly awkward from what I can see, so I'm trying to get Raspbian set up to glitch when time allows.
This is a very interesting topic but I suggest you open a dedicated thread for it as this thread is related particularly to BruteFIR Volumio plugin.

P.S. when I was using RPI 3 B+ I noticed that frequeny of glitches increased with network traffic. They were practically non existent with Internet radio (as it is mp3 stream) but quite frequent with HiRes content pulled over the nework from my NAS.
 

somebodyelse

Active Member
Joined
Dec 5, 2018
Messages
221
Likes
154
#13
This is a very interesting topic but I suggest you open a dedicated thread for it as this thread is related particularly to BruteFIR Volumio plugin.
I thought an explanation of why the plugin has glitches on the Pi with USB would be useful, but I don't intend to go any further on it here unless a fix is found. Further details in the github issue for anyone who's interested.

P.S. when I was using RPI 3 B+ I noticed that frequeny of glitches increased with network traffic. They were practically non existent with Internet radio (as it is mp3 stream) but quite frequent with HiRes content pulled over the nework from my NAS.
That's worth knowing. I had assumed it would behave that way, hence my choice to stream the highest bitrate I had available, but hadn't actually tested it.
 

graz_lag

Major Contributor
Joined
Oct 13, 2018
Messages
1,096
Likes
977
Location
Le Mans, France
#14
@somebodyelse
It would be nice opening up a thread ... within the "Home Music Servers, Computers and Streamers" sub-threads ...
100% dedicated to Linux' discussions on hardwares (SBCs or more elaborated PCs) and softwares (OS and players).
(So, perhaps two threads : hardware, software.)
The Linux's solar system offers one of the best, if not the best, way to set up an USB-DAC high end PC configuration.
I went thru the said sub-threads but did not see any as 100% focused on Linux. It's a pity ... the informations are scattered here & there right now ...
@somebodyelse : do you do it ? Otherwise I will do it.
Upon the approval of the Master of all Chefs @amirm !!!
Thanks !
 

Krunok

Major Contributor
Joined
Mar 25, 2018
Messages
3,844
Likes
1,977
Location
Zg, Cro
#15
I thought an explanation of why the plugin has glitches on the Pi with USB would be useful, but I don't intend to go any further on it here unless a fix is found. Further details in the github issue for anyone who's interested.


That's worth knowing. I had assumed it would behave that way, hence my choice to stream the highest bitrate I had available, but hadn't actually tested it.
I would also like to add that I have never heard of glitches issue on x86 platform.
 
Joined
Feb 26, 2019
Messages
12
Likes
2
#17
Regarding rPi3B+ pops and crackles, I'm actually only getting them when I have BruteFIR enabled. I've set the wired Ethernet port to 100Mbps FD which helped a lot, (presumably lowering the USB traffic helps) and am testing a few other settings people have reported have helped. Will report back when I have a chance to listen again with the changes made.
 

Krunok

Major Contributor
Joined
Mar 25, 2018
Messages
3,844
Likes
1,977
Location
Zg, Cro
#18
Regarding rPi3B+ pops and crackles, I'm actually only getting them when I have BruteFIR enabled.
I had the same experience.

I've set the wired Ethernet port to 100Mbps FD which helped a lot, (presumably lowering the USB traffic helps) and am testing a few other settings people have reported have helped. Will report back when I have a chance to listen again with the changes made.
I didn't manage to correct it, whatever I did it was still there - best i was able to do was to hear app 1 pop/minute. However, I sincerely wish you good luck! :)
 
Joined
Feb 26, 2019
Messages
12
Likes
2
#20
I had the same experience.



I didn't manage to correct it, whatever I did it was still there - best i was able to do was to hear app 1 pop/minute. However, I sincerely wish you good luck! :)
Have you tried plugging your USB Dac into a hub and then into the rPi? That's what I'm going to try next...already did a bunch of changes in cmdline.txt and whatnot which didn't really help.
 
Top Bottom