format: "S24_LE";
skip: 44;
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:
BruteFIR now loads without errors, and music plays.Code:format: "S24_LE"; skip: 44;
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.
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 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.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 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.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 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.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.
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...
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.
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.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.
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.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.
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 haven't heard them in my testing either, but they were reported by at least one user on the github issue.I would also like to add that I have never heard of glitches issue on x86 platform.
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.
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!