Hi all, over the last couple weeks I've been putting together a music system based on the idea of doing AirPlay + room correction for listening to music in my apartment. I'm still digging through the wisdom in these forums but I think it's far enough along that the configuration might be interesting to some people here. Essentially I've got a Linux netbook with a M-Audio USB audio interface on my network running Shairport (AirPlay emulation) + Brutefir (room correction). All of this goes through an amp to a pair of Infinity RS-IIIbs and the result sounds pretty good to my ears.
End result: From an iPhone or iTunes you can play music over the network and it comes out of the speakers room corrected and sounding nice.
I've put the configs online in case they are useful to someone else:
https://github.com/choongng/Music-Box
In the meantime if anyone else has set up a similar system I'd be interested in hearing how it works and what hardware you used.
End result: From an iPhone or iTunes you can play music over the network and it comes out of the speakers room corrected and sounding nice.
I've put the configs online in case they are useful to someone else:
https://github.com/choongng/Music-Box
In the meantime if anyone else has set up a similar system I'd be interested in hearing how it works and what hardware you used.
Can you give some details on specs of your computer and amount of processor load you see on it while running brutefir?
I'm hoping to try brutefir on a ARM based board but not sure how well it will take the processor intensive tasks. Boards that I am interested in are beagle bone (I have one of these already) and raspberry pi.
I'm hoping to try brutefir on a ARM based board but not sure how well it will take the processor intensive tasks. Boards that I am interested in are beagle bone (I have one of these already) and raspberry pi.
It's a little 2-core Atom Samsung netbook ("Intel(R) Atom(TM) CPU N570 @ 1.66GHz"). CPU usage is pretty low, top reports 96-98% idle. I'm not sure what that would translate to on another CPU as Brutefir looks like it's using SSE on x86. I'm not sure to what extent you can get Brutefir to use NEON (from a quick search it looks like fftw supports it) but you could probably get it to work. For little ARM boxes you might also look at TP-Link (Welcome to TP-LINK), those are cheap and will run OpenWRT. Shairport uses about as much CPU as Brutefir.
Honestly, that CPU looks so idle as if no DRC was underway. These figures would suggest the 400MHz TPLinks could perhaps handle the load which so far seemed impossible to me. Please could you profile your running processes a bit - brutefir CPU load, etc. Thanks a lot for sharing your configs on github, great help for others.
Here's top output. I would be very interested in how this stuff runs on ARM as that would simplify the setup quite a bit and on cheaper hardware.
top - 09:43:34 up 14 days, 22:52, 8 users, load average: 0.01, 0.02, 0.05
Tasks: 89 total, 2 running, 87 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.8%us, 0.7%sy, 0.0%ni, 97.4%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 2045864k total, 1021552k used, 1024312k free, 152216k buffers
Swap: 0k total, 0k used, 0k free, 720660k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5661 music RT 0 190m 4548 2720 S 5 0.2 1:11.94 shairport
5021 music RT 0 116m 9032 8268 S 3 0.4 25:07.73 brutefir.real
5022 music RT 0 116m 9020 8256 S 3 0.4 25:43.66 brutefir.real
25041 music RT 0 132m 31m 24m S 1 1.6 18:37.70 jackd
5017 music RT 0 117m 11m 10m S 1 0.6 9:04.62 brutefir.real
top - 09:43:34 up 14 days, 22:52, 8 users, load average: 0.01, 0.02, 0.05
Tasks: 89 total, 2 running, 87 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.8%us, 0.7%sy, 0.0%ni, 97.4%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 2045864k total, 1021552k used, 1024312k free, 152216k buffers
Swap: 0k total, 0k used, 0k free, 720660k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5661 music RT 0 190m 4548 2720 S 5 0.2 1:11.94 shairport
5021 music RT 0 116m 9032 8268 S 3 0.4 25:07.73 brutefir.real
5022 music RT 0 116m 9020 8256 S 3 0.4 25:43.66 brutefir.real
25041 music RT 0 132m 31m 24m S 1 1.6 18:37.70 jackd
5017 music RT 0 117m 11m 10m S 1 0.6 9:04.62 brutefir.real
I'll test later this week on 700MHz (TI AM3358 ARM Cortex-A8) beaglebone.
To start with I'll just try to replicate choongng's configuration as closely as possible and see how it goes. Will be back in a few days with success/failure/questions!
My first question is to confirm my understanding of the role of the DRC software, it just creates the filters that are implemented by brutefir correct? So if I can get playback software and jack and brutefir running then test performance we're set? Shairport is an optional extra imo, may test it later, in my final system I will probably use mpd to achieve similar outcome.
Does anyone have any benchmarking suggestions or req that may be quicker to implement and get running? I guess nothing will beat just running it.
To start with I'll just try to replicate choongng's configuration as closely as possible and see how it goes. Will be back in a few days with success/failure/questions!
My first question is to confirm my understanding of the role of the DRC software, it just creates the filters that are implemented by brutefir correct? So if I can get playback software and jack and brutefir running then test performance we're set? Shairport is an optional extra imo, may test it later, in my final system I will probably use mpd to achieve similar outcome.
Does anyone have any benchmarking suggestions or req that may be quicker to implement and get running? I guess nothing will beat just running it.
Correct, DRC is only needed to generate the filters and could be run on another machine. If you're using USB audio you could probably do the whole filter generation process on a PC and just copy the resulting filters over. For the purposes of testing performance you can run Brutefir against audio in a file and skip the ALSA + JACK configuration work.
Hi!
I also use Brutefir for active xover & drc... So your thread is really interesting
My music sources are analog sound card input and also mpd for my NAS music library. I connect the sources onto Brutefir by using JACK:
I'd like to send wireless audio from my iPad to my "JACK+Brutefir Box". I have succesfully tested shairport over an ALSA sound card. But I dont know how to send the shairport audio onto JACK in order to be processed into Brutefir as per my "JACK+Brutefir Box" configuration. Any help please?
Thx
I also use Brutefir for active xover & drc... So your thread is really interesting
My music sources are analog sound card input and also mpd for my NAS music library. I connect the sources onto Brutefir by using JACK:
Code:
system:capture_1
brutefir:input-0
system:capture_2
brutefir:input-1
system:playback_1
brutefir:1:tw_L
system:playback_2
brutefir:2:tw_R
system:playback_3
brutefir:3:wo_L
system:playback_4
brutefir:4:wo_R
system:playback_5
brutefir:5:sub_L
system:playback_6
brutefir:6:sub_R
brutefir:input-0
system:capture_1
mpd_jack:left
brutefir:input-1
system:capture_2
mpd_jack:right
brutefir:1:tw_L
system:playback_1
brutefir:2:tw_R
system:playback_2
brutefir:3:wo_L
system:playback_3
brutefir:4:wo_R
system:playback_4
brutefir:5:sub_L
system:playback_5
brutefir:6:sub_R
system:playback_6
mpd_jack:left
brutefir:input-0
mpd_jack:right
brutefir:input-1I'd like to send wireless audio from my iPad to my "JACK+Brutefir Box". I have succesfully tested shairport over an ALSA sound card. But I dont know how to send the shairport audio onto JACK in order to be processed into Brutefir as per my "JACK+Brutefir Box" configuration. Any help please?
Thx
Hi again,
I have found the solution because it was well documented into
https://github.com/choongng/Music-Box/blob/master/asoundrc
So, my PC based xover+drc is now serving as an Airport Express to my iPad/IPhone. These are the figures:
AMD Athlon(tm) 64 Processor 3500+
1Gb RAM
Gentoo
jackd 1.9.7
Brutefir running 6 x 64Ktap (2 drc + 4 two way xover)
shairport
~57% CPU load
Other system that I have built is:
MiniITX ATOM Intel D525MW
RAM 2GB
Fanless
Debian
Echoaudio Gina3G sound card
jackd 1.9.8
Brutefir running 10 x 64Ktap (2 subsonic + 2 drc + 6 three way xover)
~28% CPU load
I have found the solution because it was well documented into
https://github.com/choongng/Music-Box/blob/master/asoundrc
So, my PC based xover+drc is now serving as an Airport Express to my iPad/IPhone. These are the figures:
AMD Athlon(tm) 64 Processor 3500+
1Gb RAM
Gentoo
jackd 1.9.7
Brutefir running 6 x 64Ktap (2 drc + 4 two way xover)
shairport
~57% CPU load
Other system that I have built is:
MiniITX ATOM Intel D525MW
RAM 2GB
Fanless
Debian
Echoaudio Gina3G sound card
jackd 1.9.8
Brutefir running 10 x 64Ktap (2 subsonic + 2 drc + 6 three way xover)
~28% CPU load
Brute FIR on Beaglebone
Just found this thread .. very interesting.
Did anyone run BruteFIR on beaglebone .. I would be interested how much it consumes.
I know that the use of Neon instruction set can bring a lot - we have recently brought down the CPU consumption for a resample algorithm from
appr. 30-40% down to 5% !
Did anybody try on Beaglebone ?
cu
thomas
Just found this thread .. very interesting.
Did anyone run BruteFIR on beaglebone .. I would be interested how much it consumes.
I know that the use of Neon instruction set can bring a lot - we have recently brought down the CPU consumption for a resample algorithm from
appr. 30-40% down to 5% !
Did anybody try on Beaglebone ?
cu
thomas
I haven't, yet, I got distracted and forgot to come back to that experiment
Was planning on hooking the beaglebone up again this weekend so if I get a chance to play with it I'll post back here
It seems likely the answers are all on this page:
Downloading and Building FFTW-ARM
I get further through the make with the 3.2.2-arm source posted on that page with compile configured with:
This was the only set of options I could get that would ensure cycle timers were used rather than estimated.
Currently make fails with the following messages:
At 2am here right now, I think troubleshooting this will be a job for the morning.
Downloading and Building FFTW-ARM
I get further through the make with the 3.2.2-arm source posted on that page with compile configured with:
Code:
./configure --enable-single --enable-perf-events --enable-neon ARM_CPU_TYPE=cortex-a8This was the only set of options I could get that would ensure cycle timers were used rather than estimated.
Currently make fails with the following messages:
Code:
libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I../kernel -O3 -fomit-frame-pointer -fstrict-aliasing -ffast-math -mcpu=cortex-a8 -mfpu=neon -MT neon.lo -MD -MP -MF .deps/neon.Tpo -c neon.c -o neon.o
/tmp/cckMDuDi.s: Assembler messages:
/tmp/cckMDuDi.s:31: Error: bad instruction `vmov.f32 d0,#0.0'
make[3]: *** [neon.lo] Error 1
make[3]: Leaving directory `/home/root/fftw-3.2.2-arm/simd'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/root/fftw-3.2.2-arm/simd'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/root/fftw-3.2.2-arm'
make: *** [all] Error 2At 2am here right now, I think troubleshooting this will be a job for the morning.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.