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
thanks for the explanation. there is no way a 1ghz bbb cant handle fir filtering easily if you don't care about latency. with no partitions I bet you can run several channels up to 16k taps.
if you run "brutefir &"
then run "top"
you should be able to see how much processor and memory it is using.
It will be fun to play with! I have a few hurdles to jump before I'm able to mess with rePhase so current objectives are modest, just getting up to speed... One small challenge will be to script the BruteFIR command line interface to swap filter sets on-the-fly so that they match the variable data frequencies that the kernel manages.
Meanwhile, I appreciate reading how others solve problems using FIR tools.
Frank
do you mean you want to change the filter when the sampling rate changes? ie 48khz etc?
I use analog inputs so thats not a problem for me.
Exactly - the kernel uses clean external clocks at the proper frequency multiples to eliminate resampling and minimize phase noise. Thus, for each rePhase correction I hope to have different coefficient sets to cover 44, 48, 88, and 96 kHz source material. A python script will monitor the native PCM sample rate and point brutefir to the correct set of coefficients for that frequency.
OK, I followed the Instructables tutorial, I have a newer Raspbian so I opted for compiling my own kernel. I changed channel_max 8 (twice in the file) and compiled. Jack runs if I keep number of channels set to default, but fails if I set numbers of channels above 2. Regardless of soundcard selected. Simply setting soundcard and number of channels defaults gives two output channels in Jack.
Seems like the HDMI is not successfully presenting itself as an 8 channel card? What's wrong and what's a good new thing to try?
Output of aplay -l:
Output of aplay -L:
Output of message window of Jack (first a boot with default, then with 4 output channels):
Hello @Ivo,
1) It seems that JACK is causing serious problems. I don't know what convenience it would provide to you if it were working, but I have not needed JACK, nor is it used in JRubin's instructible.
2) I see that there are no plugs listed in your 'aplay -L' result. ALSA plugs are the key to managing the multiple channels you wish to handle. Perhaps re-read the instructible portions in which filter plugs were created and combined into an .asound.rc file or an asound.conf file in the /etc directory. Each of the plugs in the asound.conf file should be displayed by an 'aplay -L' command.
3) Since you have compiled your own kernel, and since I don't have an RPi on which to reproduce what you are working with, it would be difficult to trouble-shoot at a detailed level. I suggest that you start by reproducing JRubin's work in successful ALSA routing plugs from input to output (but no need to include LADSPA filters unless you wish). When that is working, only then will you know that your ALSA syntax, plugs and implementation are OK and that there are no hardware issues. Then transfer everything to your custom kernel. ALSA is not a forgiving system. Too many variables and assumptions are a recipe for frustration.
4) More information and examples of ALSA plugs used as crossovers are available in the following thread:
http://www.diyaudio.com/forums/twisted-pear/277564-ladspa-filters-digital-crossovers-bbb.html
I invite you to post further questions there. Also, take a look at the process by which JRubin got his RPi/HDMI system running:
http://www.diyaudio.com/forums/twis...rs-digital-crossovers-bbb-12.html#post4631927
Regards,
Frank
Last edited:
Hello Frank, thank you very much! I failed to see the relevance of the plugs, I thought they mainly served to insert the filters. I ran the aplay commands on my ubuntu laptop and saw many plugs, I wondered why. The laptop can obviously do more with it's HDMI "out of the box" and I guess that's how. Running the aplay commands on Ubunta Mate for Raspberry Pi did not give those plugs I think, but I will check again to be sure. I will get into it and ask further questions at the suggested place.
Regarding jack:
Like Loafmeat, I want to use plugins with a GUI, these CALF plugins offer a decent interface and nice set of parameters and are easily tied together with Jack. I have had multichannel working with my ubuntu laptop and it is great, modifying parameters on the fly by dragging your mouse. Very much like for instance a minidsp or hypex device. I had it working with two-channel on the pi, so it should be down to getting access to those multichannel outputs of the HDMI.
Some of the calf plugins:
Regarding jack:
Like Loafmeat, I want to use plugins with a GUI, these CALF plugins offer a decent interface and nice set of parameters and are easily tied together with Jack. I have had multichannel working with my ubuntu laptop and it is great, modifying parameters on the fly by dragging your mouse. Very much like for instance a minidsp or hypex device. I had it working with two-channel on the pi, so it should be down to getting access to those multichannel outputs of the HDMI.
Some of the calf plugins:
Dear Ivo
I am happy to hear that one Person is also using CALF.
To your remark to Multichannel.
Have you checked the EDID and supported audio formats of the connected Monitor/AVR.
If the EDID of your Monitor only has 2 Channel you can get only 2
Here are some good informations regarding this.
HDMI Audio on NVIDIA GPUs
Regards
Guenter
I am happy to hear that one Person is also using CALF.
To your remark to Multichannel.
Have you checked the EDID and supported audio formats of the connected Monitor/AVR.
If the EDID of your Monitor only has 2 Channel you can get only 2
Here are some good informations regarding this.
HDMI Audio on NVIDIA GPUs
Regards
Guenter
I have a Marantz NR1603 receiver, 7.1 channel. It should give out the right signals etc. I will work on those plugs first and see where we get. Thanks for publishing your calf plugin experiments Guenter.
I can quickly put together some ALSA plugs that you can load in order to have multichannel output. Two questions: 1) What music player software do you use (like, squeezelite, MPD, volumio, etc.), and 2) how many channels do you want?
Frank
Generous offer, Frank!
1) At the moment, VLC media player. It can output to ALSA or to JACK. I have been using the jack output, but I guess it doesn't matter (there are various ways to get ALSA into Jack).
2) Does processorload increase directly in relation to number of channels? In that case 2 input/4 output is enough. If unconnected channels do not contribute directly to processorload, 2 input/8 output or even 6 input/8 output would be nice.
I have been reading up about ALSA plugs last night, interesting stuff. I sort of understand what the different bits of text do, but writing my own/modifying someone else's was a bit too far-fetched for one night. The links out of your BBB thread are very useful. There is much to learn about ALSA.
1) At the moment, VLC media player. It can output to ALSA or to JACK. I have been using the jack output, but I guess it doesn't matter (there are various ways to get ALSA into Jack).
2) Does processorload increase directly in relation to number of channels? In that case 2 input/4 output is enough. If unconnected channels do not contribute directly to processorload, 2 input/8 output or even 6 input/8 output would be nice.
I have been reading up about ALSA plugs last night, interesting stuff. I sort of understand what the different bits of text do, but writing my own/modifying someone else's was a bit too far-fetched for one night. The links out of your BBB thread are very useful. There is much to learn about ALSA.
OK @Ivo, I prepared a test ALSA configuration to get you started. It is over on the LADSPA thread: http://www.diyaudio.com/forums/twis...rs-digital-crossovers-bbb-27.html#post4991733
Once you've verified your HDMI output, then you can start troubleshooting JACK. If that is too much bother, then you have the option of inserting LADSPA crossover filters in the asound.conf file to at least get something. That's all discussed on that other thread.
Processor load only depends on the amount of processing, not the number of channels in which it is conducted. Note that JRubin's crossover and EQ plugs would not be optimal for a BBB, but they seem to work fine on his RPi. In general, when trying plugs, best to take your code from github, because the DIY audio "code boxes" sometimes change certain sequences of characters. ...but I think the contents waiting there for you is ok...
Cheers!
Frank
Once you've verified your HDMI output, then you can start troubleshooting JACK. If that is too much bother, then you have the option of inserting LADSPA crossover filters in the asound.conf file to at least get something. That's all discussed on that other thread.
Processor load only depends on the amount of processing, not the number of channels in which it is conducted. Note that JRubin's crossover and EQ plugs would not be optimal for a BBB, but they seem to work fine on his RPi. In general, when trying plugs, best to take your code from github, because the DIY audio "code boxes" sometimes change certain sequences of characters. ...but I think the contents waiting there for you is ok...
Cheers!
Frank
please share when you do this.
I have gotten to the point of looking at how to kill and re-start BruteFIR and have found that it won't be as easy as I hoped. I usually use the following command to sense sample rates:
Code:
root@beaglebone:~# cat /proc/asound/Botic/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 8
rate: 96000 (96000/1)
period_size: 256
buffer_size: 4096I then simply isolate the digits from the output string and do logic on them. However, BruteFIR sets what hardware sample rate will be reported (i.e., whatever frequency is in its configuration file), blocking the sensing of different native sample rates of the input music files. The output never changes while BruteFIR is running.
For now I will shelve this idea and finish building my new woofers. Until they are done, I don't really know what filters I'll want to run. But if there are any suggestions for sensing a music file's native rate on the BBB, I'll happily try them out...
Cheers,
Frank
Last edited:
I have gotten to the point of looking at how to kill and re-start BruteFIR and have found that it won't be as easy as I hoped. I usually use the following command to sense sample rates:
Code:root@beaglebone:~# cat /proc/asound/Botic/pcm0p/sub0/hw_params access: MMAP_INTERLEAVED format: S32_LE subformat: STD channels: 8 rate: 96000 (96000/1) period_size: 256 buffer_size: 4096
I then simply isolate the digits from the output string and do logic on them. However, BruteFIR sets what hardware sample rate will be reported (i.e., whatever frequency is in its configuration file), blocking the sensing of different native sample rates of the input music files. The output never changes while BruteFIR is running.
For now I will shelve this idea and finish building my new woofers. Until they are done, I don't really know what filters I'll want to run. But if there are any suggestions for sensing a music file's native rate on the BBB, I'll happily try them out...
Cheers,
Frank
could you set brutefir to close if sample rate is different,using
"monitor_rate: true;" #abort if incoming sample rate is different from config
then do a script that will read the sample rate and load the correct brutefir filter?
Sounds promising! We'd need an efficient trigger that senses if brutefir aborts...
Will ponder from the woodworking shop!
Let me know if I can provide other example Python code if you want to explore scripting this yourself...Frank
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.