Volumio & BruteFIR related discussion

[Krunok]

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.

Yes, no change with that. I also discovered it actually works better with WiFi than with wired network but I still got pops with BruteFIR active.

 

[verkion]

I should probably mention what I've tried so far...can compare notes that way. Also, you are right, WiFi still clicks as well.

1) Limit Ethernet to 10/100 FD: edited /etc/rc.local and inserted line /sbin/ethtool -s eth0 speed 100 duplex full autoneg on

2) Disabled Energy Efficient Ethernet: edited /boot/config.txt and inserted line dtparam=eee=off

Next set of edits all done to /boot/cmdline.txt
3) DMA mode for accessing FIFO: dwc_otg.dma_enable=1
4) DMA burst size to 256 (from 32): dwc_otg.dma_burst_size=256
5) Adjust scheduler: dwc_otg.microframe_schedule=1

I'm going to run some tests right now with different filter sizes/sample rates again and test WiFi again. I know for sure it is still clicking with Ethernet + Filter Size: 131072 + Sample Rate 192KHz. Going to try changing to Ethernet + Filter Size 65536 + Sample Rate 96KHz then with WiFi with those two Filter/Sample. Didn't get a chance to try last night because baby was sleeping.

Also...I might give forcing USB 1.0 a try + WiFi which means 96KHz files will be max? Should be OK though we can set BruteFIR to 96KHz sample rate anyways which is probably more than enough...

[UPDATE]
Ok. Just tried all iterations of Ethernet/WiFi + Filter Size variations + Sample Rate changes... Still pops.

Then, I tried forcing USB1.1 + WiFi and...no pops/clicks! But, it seems some DSD files etc. won't play due to insufficient bandwidth issues.

I guess the only "solution" for the time-being is to move to Odroid or x86 etc.
[/UPDATE]

Thanks!
verkion

 

[Krunok]

I guess the only "solution" for the time-being is to move to Odroid or x86 etc.

That was my conclusion as well.

 

[verkion]

That was my conclusion as well.

I have a tinker board coming tomorrow to try out...I'll post the results when I try it out tomorrow.

Thanks!
verkion

 

[Biblob]

Another cheap x86 board is the Aaeon UpBoard from Intel. It's $90 and has a z8350-atom chip, 4gb ram, gigabit ethernet, 32 GB emmc.
Found here

 

[verkion]

Another cheap x86 board is the Aaeon UpBoard from Intel. It's $90 and has a z8350-atom chip, 4gb ram, gigabit ethernet, 32 GB emmc.
Found here

Pricey compared to the odroid, rpi and tinker board s, vi etc.

Any of the "modern" boards should be able to handle bruteFIR computations...just a matter of which ones don't have playback issues due to poor board implementation. And I suppose what features you want (touchscreens etc.).

 

[Biblob]

I agree, but for a x86 application, it's pretty good priced though.

 

[verkion]

Does BruteFIR + DAC hat on rPi crackle/pop? Or is it just a USB thing? I'm thinking maybe I'll test out a hat as well...like a Piano 2.1 if I can find one or the Allo Katana.

Thanks!
verkion

 

[Krunok]

Does BruteFIR + DAC hat on rPi crackle/pop? Or is it just a USB thing? I'm thinking maybe I'll test out a hat as well...like a Piano 2.1 if I can find one or the Allo Katana.

Thanks!
verkion

It doesn't, it is just a USB thing.

 

[verkion]

Well then...rPi + Katana...here I come!

 

[pierre]

I should probably mention what I've tried so far...can compare notes that way. Also, you are right, WiFi still clicks as well.

1) Limit Ethernet to 10/100 FD: edited /etc/rc.local and inserted line /sbin/ethtool -s eth0 speed 100 duplex full autoneg on

2) Disabled Energy Efficient Ethernet: edited /boot/config.txt and inserted line dtparam=eee=off

Next set of edits all done to /boot/cmdline.txt
3) DMA mode for accessing FIFO: dwc_otg.dma_enable=1
4) DMA burst size to 256 (from 32): dwc_otg.dma_burst_size=256
5) Adjust scheduler: dwc_otg.microframe_schedule=1

I'm going to run some tests right now with different filter sizes/sample rates again and test WiFi again. I know for sure it is still clicking with Ethernet + Filter Size: 131072 + Sample Rate 192KHz. Going to try changing to Ethernet + Filter Size 65536 + Sample Rate 96KHz then with WiFi with those two Filter/Sample. Didn't get a chance to try last night because baby was sleeping.

Also...I might give forcing USB 1.0 a try + WiFi which means 96KHz files will be max? Should be OK though we can set BruteFIR to 96KHz sample rate anyways which is probably more than enough...

[UPDATE]
Ok. Just tried all iterations of Ethernet/WiFi + Filter Size variations + Sample Rate changes... Still pops.

Then, I tried forcing USB1.1 + WiFi and...no pops/clicks! But, it seems some DSD files etc. won't play due to insufficient bandwidth issues.

I guess the only "solution" for the time-being is to move to Odroid or x86 etc.
[/UPDATE]

Thanks!
verkion

Before tweaking parameters all over the place, can you profile the application under load? Or do you already know what’s happening? CPU contention, interrupts badly spiltted across core or whatever?

I resample at 48khz on the rpi for this reason. For listening that change absolutely nothing and make my life simple.
On a celeron, I run BruteFIR with 17 channels in // without issues.

 

[verkion]

Before tweaking parameters all over the place, can you profile the application under load? Or do you already know what’s happening? CPU contention, interrupts badly spiltted across core or whatever?

I resample at 48khz on the rpi for this reason. For listening that change absolutely nothing and make my life simple.
On a celeron, I run BruteFIR with 17 channels in // without issues.

I'm definitely not an expert on any of this (new rPi user), but it is a known USB DAC + rPi 3B+ issue apparently. I was just testing suggestions made by a number of other users here and there/consolidating the results in one place. Under load with a "top" command, BruteFIR shows 30% or so usage per channel. If you have any other ideas for logging/testing, I'm more than happy to try it out.

Also...x86 doesn't have this issue.

Thanks!
verkion

 

[somebodyelse]

Before tweaking parameters all over the place, can you profile the application under load? Or do you already know what’s happening? CPU contention, interrupts badly spiltted across core or whatever?

Check the issue at github for the current work on tracking this down. There has been some progress over the last week, helped enormously by someone working on some XMOS audio device code, seeing what the audio device sees. It looks like there are (at least) 2 causes of the same audible symptom, one of which has only been seen on the Pi so far, and happens much more often with kernel 4.19.x than 4.4.x. Another happens on both the Pi and Tinker Board with kernel 4.4.x so predates the softirq changes in 4.9, but doesn't appear on the Pi running 4.19.x.

 

[somebodyelse]

In my raspbian-based test setup limiting it to 1 cpu core seems to stop the glitches. I did this by adding 'maxcpus=1' to the end of the kernel command line in /boot/cmdline.txt abd rebooting. With brutefir outputting 96kHz s32_le on 2 channels and squeezelite streaming 24/352 flac dxd samples sourced from 2l.no the cpu was at ~30% an I didn't hear any glitches. I now need to look at how to pin processes to specific cpus to see if the same result can be had without reducing available processing power.

 

[somebodyelse]

After some further testing it seems I only need to pin brutefir to one cpu core to avoid glitches (or at least make them rare enough that I'm not certain they're happening - I really need an objective test to find them.) This can be done using taskset when starting brutefir, such as:
sudo taskset -c 1 brutefir /home/pi/brutefir.cfg &
No modifications to /boot/cmdline.txt are needed - no need to add the maxcpus parameter mentioned in my last post, or the isolcpus parameter I was looking at. It still means brutefir has limited processing power available, but not as limited as with the maxcpus limit set, and it seems adequate for 96kHz output.

 

[reza]

I have been playing around with BruteFIR and Volumio for a while. I usually start by measuring sweeps in REW, averaging, making EQ files, and generating FIR files in rePhase.

One thing that I haven't yet been able to do is measure the result. The problem is that BruteFIR resides on the RPi where REW cannot work. Following REW's instructions for offline measurement, I have generated sweeps with timing references, which I can play from the RPi. I record those sweeps with Audacity. When I try to import the recorded wav file as a sweep, REW complains that the file doesn't have the necessary data. I can also import it as an audio file, which does work, but the recorded level of the sound is so low that noise dominates - I have independently confirmed that the signal to noise ratio is low by listening to the recorded audio. My living room is not particularly noisy. Anyway, all this confuses me about two things:

1-Is it normal for the recorded sound level to be so low? How does REW manage to get good signal with the same setup and volume settings, but Audacity fails to capture any useful signal? Am I missing something here? Before a measurement I run a check levels and get the OK from REW. But when I record with the same level settings, audacity hears mostly noise.

2-More generally, how do you guys measure the result of your correction on RPi or comparable devices? I know I can import the FIR file in REW and convolve it for a predication. But that's not what I'm after here. Do you resort to offline measurement as I described above? If so, have you ever noticed any of this nonsense with missing data or dominant noise?

 

[Daverz]

I gave a description of how to record using REW when playing back thru your RPi (I'm using LMS and piCorePlayer, but the principal is the same).

https://www.audiosciencereview.com/...orial-for-dummies-part-2.5/page-9#post-163964

The key is to "Add Timing Ref" when you create your sweep in REW and then "Use acoustic timing reference" when you take the measurement.

 

[reza]

I gave a description of how to record using REW when playing back thru your RPi (I'm using LMS and piCorePlayer, but the principal is the same).

https://www.audiosciencereview.com/...orial-for-dummies-part-2.5/page-9#post-163964

The key is to "Add Timing Ref" when you create your sweep in REW and then "Use acoustic timing reference" when you take the measurement.

I actually tried that. But it didn't work, which I suppose was because of the low levels on the mic; REW couldn't hear the timing reference signal. I think the mic is faulty.

 

[Krunok]

I actually tried that. But it didn't work, which I suppose was because of the low levels on the mic; REW couldn't hear the timing reference signal. I think the mic is faulty.

Or it has not been properly configured. You can check it using SPL meter in REW.

 

[reza]

Or it has not been properly configured. You can check it using SPL meter in REW.

I mean, even independent of REW, for instance in windows voice recorder or Audacity, the mic doesn't seem to function properly. I have to bring it right up to my mouth, or it only captures noise. Mic level is set to 100% and mic boost set to +10dB in windows.