Cool. I looked over the tutorial, as it focused so heavily on the non-GUI LADSPA stuff. But of course I can use the multichannel over HDMI part. At least try. Then tie that to Jack and weŕe off with the GIU IIR stuff.
I am attempting to answer some of my own questions by getting brutefir running on a BBB. I want to compare it to the convolver in SoX, which I have already used on the BBB. One problem - a text-type coefficient set that runs in SoX causes this error report in brutefir:
Code:
BruteFIR v1.0m (November 2013) (c) Anders Torger
Internal resolution is 32 bit floating point.
Creating 4 FFTW plans of size 4096...finished.
Loading 2 coefficient sets...Parse error on line 5 in file /root/firfilters/fir2peak48-2048.txt: invalid floating point number.The format of the coefficients is like:
Code:
-1.26E-06
-1.40E-06
-1.44E-06
-1.38E-06
-1.22E-06
-9.87E-07
...Any suggestions greatly appreciated!
Frank
Which is the actual line 5 as parsed? On the surface this looks OK but I have had problems where the input was just being read until something bad happened.
OK so it makes no sense, -1.26E-06 is good and -1.22E-06 is bad. Is the E case sensitive? This really is acting like the parser is seeing nothing but what it thinks is garbage and only chokes when so many invalid characters have been read.
Yes indeed, if anyone is using for instance NotePad++ then go to...
Edit -> EOL Conversion -> and set correct Win, UNIX/OSX, old Mac EOL
EOL = End of Line
these invisible characters causes trouble when compiling if the code contains incorrect EOL's, I ones learned the mistake while writing C code on Codeblocks in Windows and then taking the code to be compiled in a Linux machine.
also, one can make these special EOL characters visible by going to...
View -> Show Symbol -> Show End of Line
In NP++ the characters look like...
Windows = [CR][LF]
UNIX/OSX = [LF]
Old MAC = [CR]
Thanks very much in advance! Because I'm completely new to BruteFIR errors are probable, however I did start by copying a .config version reported to work with a RPi and then I tried to adapt it to my 2048 (+ center) coefficient set. ...so is that 2048 or 2049?
Also, there is a '.brutefir.config' file as well as this one - source of confusion?
Code:
## DEFAULT GENERAL SETTINGS ##
float_bits: 32; # internal floating point precision
sampling_rate: 48000; # sampling rate in Hz of audio interfaces
filter_length: 2048, 1; # length of filters
#config_file: "~/.brutefir_config"; # standard location of main config file
overflow_warnings: true; # echo warnings to stderr if overflow occurs
show_progress: false; # echo filtering progress to stderr
max_dither_table_size: 0; # maximum size in bytes of precalculated dither
allow_poll_mode: false; # allow use of input poll mode
modules_path: "."; # extra path where to find BruteFIR modules
monitor_rate: false; # monitor sample rate
powersave: true; # pause filtering when input is zero
lock_memory: true; # try to lock memory if realtime prio is set
sdf_length: -1; # subsample filter half length in samples
safety_limit: -0.01; # if non-zero max dB in output before aborting
convolver_config: "~/.brutefir_convolver"; # location of convolver config file
## COEFF DEFAULTS ##
coeff "c-l" {
filename: "/root/firfilters/fir2peak48-2048.txt";
format: "text";
};
coeff "c-r" {
filename: "/root/firfilters/fir2peak48-2048.txt";
format: "text";
};
## INPUT DEFAULTS ##
#
input "left_in", "right_in" {
device: "alsa" { device: "hw:0,0"; ignore_xrun: true; };
# sample: "S16_LE";
};
## OUTPUT analog
#
output "left_out", "right_out" {
device: "alsa" { device: "hw:1,0"; ignore_xrun: true; };
# sample: "S16_LE";
dither: true;
};
## FILTER DEFAULTS ##
filter "drc_l" {
from_inputs: "left_in";
to_outputs: "left_out";
coeff: "c-l";
};
filter "drc_r" {
from_inputs: "right_in";
to_outputs: "right_out";
coeff: "c-r";
};hi franco,
I dont know if this helps but these are the first few lines of a .txt filter that i use
maybe it just doesnt like the other format?
0
0.0000000000010802893623386621
-0.0000000000043535524902080108
0.0000000000091476628343843586
-0.00000000001874966780410529
0.00000000002389777362268592
-0.000000000044966970127362191
0.000000000044310612300565024
-0.000000000084154306694242858
0.000000000070165737664286393
-0.00000000013652810403981025
0.00000000010225248194375945
I dont know if this helps but these are the first few lines of a .txt filter that i use
maybe it just doesnt like the other format?
0
0.0000000000010802893623386621
-0.0000000000043535524902080108
0.0000000000091476628343843586
-0.00000000001874966780410529
0.00000000002389777362268592
-0.000000000044966970127362191
0.000000000044310612300565024
-0.000000000084154306694242858
0.000000000070165737664286393
-0.00000000013652810403981025
0.00000000010225248194375945
In general if you ever write a text file in Windows it's best to transfer it to linux via ftp so that automatic format translation happens. Alternatively if you just do a file copy you will have format mismatch problems but can just run the Linux program 'dos2unix' on the file to sort it out.
Confirmed - it is the .txt file. I have been uploading the .txt files using FTP. Even so, they never worked by substituting new dashes, small 'e', new line returns, etc. Those changes only moved the line number at which the parser failed.
I took @1201's suggestion and converted to all-decimal format. Now that problem is solved.
While these test coefficients were generated in Matlab, my final application files will probably be generated by rePhase.Next steps are to continue configuring this BBB test platform as a music player with proper brutefir inputs and output interfaces.
As an aside, I was encouraged when I recently read that the number of taps available in a miniDSP are in the realm of what I expect the BBB to handle.
Many thanks gents!
Frank
Good these problems can be something else I spent a day once before I realized 24bit packed .wav files were byte swapped on odd boundaries on SUN workstations (they used Moto processors like MAC's).
It's like a RPi but without the well-known data bottleneck.
https://beagleboard.org/black
It was adopted some time ago as a platform for high-quality rendering so a) there is a custom Debian kernel for managing input of high quality external clocks, and b) there is a cape setup by Twisted Pear Audio for extracting up to 4 streams of very clean I2S (8 channels). It also does DSD.
a) http://www.diyaudio.com/forums/twisted-pear/258254-support-botic-linux-driver.html
b) http://www.diyaudio.com/forums/twisted-pear/272053-hermes-bbb-botic-cape-beaglebone-black.html
I have been pushing to see how much work the BBB can do in addition to merely rendering asynchronous data as I2S. Mine also does IIR filtering for 3-way crossover -> multi-amped speakers, plus lots of I2C-based control of the DACs. Now I'm addressing crossover phase questions, hence the interest in BruteFIR and rePhase. If the BBB doesn't have the starch to also run effective FIR phase correction filters, I'll eventually try to pre-treat the data at the server level.
...hopefully not TMI!
Frank
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.