Hi,
I’m trying to add a nanomsg package. It’s cmake-build-based, that works. However at runtime libanl.so.1 is missing.
I find it in target_*/lib/, together with other libc-stuff. But it is not transferred to root_*/lib (including a few others).
Is there a way to enable this using e.g. PKG_NEEDS or a similar mechanism?
Cheers,
Diez
Hi,
I’d like to discuss an idea that has been raised by some members of my team:
Working on the mac requires us to work on an explicitly mounted case-sensitive file system.
Normally our devs prefer to work from within a specific file-location, e.g. ~/workspace or similar arrangements, that is not case-insensitive.
This doesn’t work for OpendADK obviously.
So we took a look into introducing an ADK_OUTPUT_DIR environment variable. When this is given, it puts most of the generated files into the output dir (under the otherwise same names).
The thing mostly missing is the various Config.* files generated, as kconfig seems to insist that these are relative to each other and can’t deal with some sort of include-paths.
As a side-effect, this work uncovered a few places that got mildly cleaned up (such as prereq.mk and some hard-coded paths like ${STAGING_TARGET_DIR}/scripts that should read ${SCRIPT_TARGET_DIR} etc.
Of course when not using this, there should be no effect, and as far as I can see, there is none.
My question is: as this is a bigger change, maybe even philosophical in nature, I’d like to get opinions of the community first, before investing more. Because if nobody wants it, and it’s not taken into consideration while working on OpenADK, it might quickly fall into disrepair, and then it’s better to not do it at all :)
I tried to push the changes (two commits) for review on a branch to gogs.waldemar-brodkorb.de <http://gogs.waldemar-brodkorb.de/>, but that got stuck and didn’t progress even after a long wait - so maybe there is something awry there.
Cheers,
Diez
Hi,
I’m trying to build a system for the beaglebone black. It fails when compiling the kernel. See the attached information.
Any suggestions to what has gone wrong?
Cheers,
Diez
Hello,
Would you consider making a GitHub account and host the code there? It is just that it would be so much easier to send and discuss patches that way instead of with a mailing list. I used buildroot before on linux and never took the time to send patches because of the procedure. Now I am on macOS so I switched to openADK which works nicely! (especially the update-patches is nice). Would you maybe be open to that?
FYI, Here is a list of issues I encountered:
- raspberry pi 1 model B+ is my board. The kernel did not compile. Then I added some needed config values like from the official defconfig, and then it compiled. But it did not boot my system. Then I selected to use the supplied defconfig from the kernel, and now it boots and works.
- I had some issues compiling glib-host on a latest generation macbook with Xcode 8.3.2, it seems I had an extra uuid.h file in the include directory, which made compiling fail because it was not using the one from my system. Then it did not link to the AppKit framework in the end, which I fixed with setting the HOST_LDFLAGS in the package
- qtbase: seems I needed to apply the patch in attachment to make it compile with Qt 5.7.0, which is taken from 5.9. Also, the detection of the xcodebuild needed to be fixed.
Best regards
Tom,
Hi
Well, thanks to wbx, brutefir runs again! :-)I reran the performance test on my core2duo machine on an asus-p5bvm in adk with kernel 4.4.50-1.For the 30:00 test file it now takes 18 seconds!This is a 40% performance increase compared to earlier runs using adk on the same machine! :-)Also, this is now the same runtime I had on this machine running lfs with kernel 3.10.10.It is encouraging to now get the same runtime.Though I do not know where the performance boost comes from. Does anyone have an idea?
The next step will be to rerun the test on the pi2, to see if it runs faster there as well.
CheersOliver
----- Weitergeleitete Message -----
Von: "lich000king(a)yahoo.de" <lich000king(a)yahoo.de>
An: "dev(a)openadk.org" <dev(a)openadk.org>
Gesendet: 21:09 Mittwoch, 2.Dezember 2015
Betreff: BruteFIR performance test
Hi there
So, I have also run the test on my Hummingboard i2ex. Here it takes around 4.5 minutes, i.e. almost 50% longer than on the pi 2.On the core2duo machine I have also repeated the test in adk. It takes around 30 seconds, more than 50% longer than on the same machine running lfs (linux 3.10.10). This may well be due to a not optimized kernel config. I will need to delve deeper into this to find out.
Any ideas and comments are welcome:-)
CheersOliver
----- Weitergeleitete Message -----
Von: lich000king <lich000king(a)yahoo.de>
An: dev(a)openadk.org
Gesendet: 20:47 Dienstag, 27.Oktober 2015
Betreff: BruteFIR performance test
Hi again
Performed the same test on my core2duo machine (approx. 10 years old).
It takes around 18 seconds. So it is roughly 10x faster.
Does this sound reasonable or should I expect better performance from the raspberry pi 2?
The test is designed to use two cores only.
I have not managed setting up OpenADK on this machine yet, so this test ran on lfs (linux 3.10.10-rt7). But this should not affect the results much.
I also tried to run the test on the hummingboard. But there BruteFIR gives me an error which I don't quite understand:
BruteFIR v1.0m (November 2013) (c) Anders Torger
Internal resolution is 32 bit floating point.
Creating 4 FFTW plans of size 8192...finished.
Loading coefficient set...finished.
Failed to open module "file" in "/usr/lib/brutefir/file.bfio": /usr/lib/brutefir/file.bfio: undefined symbol: __aeabi_idivmod.
It looks like a problem with a floating point operation.
If anyone has any insight to any of these it will be much appreciated. :-)
Cheers
Oliver
On 18.10.2015 14:58, lich000king wrote:
Hi everyone
I am still wondering if it is possible to improve brutefir performance on arm.
In order to assess the convolution performance, I have prepared a little test procedure.
So here is how to test BruteFIR performance on OpenADK:
I used adk revision 463aa3b 2015-10-14 | update firmware and kernel to latest.
In order to perform this test you have to build adk with brutefir and sox packages (for now better don't enable PREEMPT_RT_FULL as there is an unresolved conflict with the bcm driver).
In adk do the following:
**********************************************************************************
rw
mkdir /root/bftest
cd /root/bftest
cat > /root/bftest/wavtest.conf << "EOF"
# Begin /root/bftest/wavtest.conf
# File used for testing brutefir
# Uses dirac pulse als filter.
# Stereo only. Input from file /root/bftest/pinknoise.wav. Output to file /root/bftest/output.wav.
## DEFAULT GENERAL SETTINGS ##
float_bits: 32; # internal floating point precision
sampling_rate: 44100; # sampling rate in Hz of audio interfaces
filter_length: 4096,16; # length of filters
# config_file: "/home/audiovero/.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: "/usr/lib/brutefir"; # extra path where to find BruteFIR modules
monitor_rate: true; # monitor sample rate
powersave: -80; # pause filtering when input is zero
lock_memory: false; # try to lock memory if realtime prio is set
convolver_config: "/root/bftest/brutefir_convolver"; # location of convolver config file
#benchmark: true;
## LOGIC ##
logic: "cli" { port: 3000; };
## COEFFS ##
coeff "dirac" {
filename: "dirac pulse";
format: "FLOAT64_LE";
};
## INPUT, OUTPUT ##
input "fleft", "fright" {
device: "file" { path: "/root/bftest/pinknoise.wav"; skip: 44;}; # ignore_xrun: true; };
sample: "S16_LE";
channels: 2/0,1;
};
output "fr", "fl" {
# device: "alsa" { device: "hw:0";}; # ignore_xrun: true; };
device: "file" { path: "/root/bftest/output.wav"; };
sample: "S16_LE";
channels: 2/0,1;
dither: true;
};
## FILTERS ##
filter "frfilter" {
from_inputs: "fright";
to_outputs: "fr";
coeff: "dirac";
};
filter "flfilter" {
from_inputs: "fleft";
to_outputs: "fl";
coeff: "dirac";
};
# End /root/bftest/wavtest.conf
EOF
# generate 30 minutes of pink noise as test input for brutefir
sox -t sl -r 44100 -c 2 /dev/zero -r 44100 -c 2 -b 16 pinknoise.wav synth 30:00 pinknoise vol 0.6
# run brutefir once in order to generate fftw plans (you can cancel this as soon as you see the "Audio processing starts now..."):
brutefir -nodefault /root/bftest/wavtest.conf
# Then measure the time it takes to convolve this test file by doing:
time brutefir -nodefault /root/bftest/wavtest.conf
**********************************************************************************
The first test will not give the correct time since it has to generate FFWT plans which takes quite some time. So you can cancel it the first time as soon as you see the "Audio processing starts now..." and restart it. The second time it will start convolving immediately.
On my rpi2 it takes approx. 3 m 10 s to 3 m 20 s.
The question now is if there is a way to improve brutefir performance on arm, possibly by using some hand coded assembler.
Happy testing and thanks for any feedback!
All the best
Oliver
