For the lazy or not so linux-savy users I have uploaded one complete image: 2019-01-06_nhz6wnwr | Files.fm.
After download verify following sha256 checksum before proceeding:
To write it to the sdcard (min. 4GB required) issue
It is fully default Arch Linux ARM installation image with root passwd "root" and user alarm with passwd "alarm" (you want to change both after installation!). In addition the kernel with botic driver (for Hermes BBB / Chronus) as well as mpd is installed, no other changes were done.
BBB users should get a DHCP IP from their router and can then ssh into the machine. For wireless connection first logon with serial console is required in order to setup the connection. As an alternative, if you have working network connection when booting from eMMC you can also chroot into the sdcard image to setup the network connection.
This loads by default the SABRE32 overlay which assumes ES9018 DAC connected to the I2C header of the Hermes-BBB cape. In case you have another DAC or want to make different use of the I2C header you need to edit /boot/boot.txt to load the BOTIC-00A0.dtbo overlay instead.
After download verify following sha256 checksum before proceeding:
Code:
5a808d79d3450dcaa4674937bed0b31d57316794efa7b066d857db8cd0104890To write it to the sdcard (min. 4GB required) issue
Code:
xzcat botic.img.xz | dd of=/dev/mmcblkXIt is fully default Arch Linux ARM installation image with root passwd "root" and user alarm with passwd "alarm" (you want to change both after installation!). In addition the kernel with botic driver (for Hermes BBB / Chronus) as well as mpd is installed, no other changes were done.
BBB users should get a DHCP IP from their router and can then ssh into the machine. For wireless connection first logon with serial console is required in order to setup the connection. As an alternative, if you have working network connection when booting from eMMC you can also chroot into the sdcard image to setup the network connection.
This loads by default the SABRE32 overlay which assumes ES9018 DAC connected to the I2C header of the Hermes-BBB cape. In case you have another DAC or want to make different use of the I2C header you need to edit /boot/boot.txt to load the BOTIC-00A0.dtbo overlay instead.
nice!
I could make it work on a BBBW! With chroot enabled netctl for onboard wifi.
But ran into another problem.
I installed roonbridge, no errors but when I "enable" the network device in roon, the roonbridge.service fails. The device is not visible in roon anymore and it's not possible to stop the service or even reboot.
Any suggestions?
Never used Roon and I am not planning to change that... Have you tried to simply use the package available from Archphile: playground/roonbridge-archphile-arm7 at master * archphile/playground * GitHub
Had to edit the PKGBUILD to update the sha sum of the Roon file to generate the package. Could install and start the service however I cannot test it without a Roon account...
Had to edit the PKGBUILD to update the sha sum of the Roon file to generate the package. Could install and start the service however I cannot test it without a Roon account...
I found that if you are using wifi, you should definitely enable the hardware random number generator (for some reason not enabled by default):
Code:
pacman -S rng-tools
systemctl enable rngd.service
systemctl disable haveged.serviceand then reboot. For me wifi connection was not really reliable: sometimes BBBW failed to connect after boot and I had to press reset often until I got connection. Now using rngd service this always works on the first reboot.
Hey guys,
does anyone know how to tell Botic (or ALSA) to have max DSD format at 45MHz?
I'm running HQPlayer's NAA on my BBB, and here's the part of its log:
The master clock module is 45Mhz, and I have "snd_soc_botic.clk_44k1=45158400" set in uEnv.txt
The goal is to have DSD1024 in HQPlayer
Wondering maybe someone had this problem before or successfully played DSD1024?
Thanks,
Fedor
does anyone know how to tell Botic (or ALSA) to have max DSD format at 45MHz?
I'm running HQPlayer's NAA on my BBB, and here's the part of its log:
So the max rate it detects is 22MHz.
The master clock module is 45Mhz, and I have "snd_soc_botic.clk_44k1=45158400" set in uEnv.txt
The goal is to have DSD1024 in HQPlayer
Wondering maybe someone had this problem before or successfully played DSD1024?
Thanks,
Fedor
Last edited:
I tried to do what you explain in github.com/coroner21/linux-am33xbot (README.md).
The hardware is a Beaglebone Black hardware running your last archlinux software image.
However I have a series of errors it seems due to failure to create directories / writing files, as if there are no permissions to create the various directories inside the directory "linux-4.20".
On the other hand, the execution of makepkg is possible only if you are not root ...
Where is my mistake?
I have to say that I'm not an Archlinux expert ..
Thank you
The hardware is a Beaglebone Black hardware running your last archlinux software image.
However I have a series of errors it seems due to failure to create directories / writing files, as if there are no permissions to create the various directories inside the directory "linux-4.20".
On the other hand, the execution of makepkg is possible only if you are not root ...
Where is my mistake?
I have to say that I'm not an Archlinux expert ..
Thank you
Hi gieffe, I assume you run it as a normal user that has write access to the directory you are in? Don’t forget to remove the .git directory after cloning of the git repository. Please also note that running the steps of the github readme is not recommended to be done on the beaglebone black itself. Instead, a x86-64 archlinux machine (VM also possible) should be used and only the final package copied over.
What you describe could also mean that there is no storage space? Anyways, please post some additional information about what you’re doing and the exact failures.
What you describe could also mean that there is no storage space? Anyways, please post some additional information about what you’re doing and the exact failures.
Quick update: GitHub - coroner21/linux-am33xbot: Arch Linux ARM Kernel with botic patches was updated to linux kernel version 5.0.
Great! Does power mgmt work? The 4.8.13 knows nothing about governors / sleep / mem mode...
Thanks, will try to figure out the way to pass this to kernel cmdline...
Regarding power mgt: what I could verify is cpufreq working fine. Sleep / standby I never tested, not sure if it is at all implemented for BBB.
For the GPIO pins: Kernel cmdline is not the right thing here. You will need to regenerate the device tree and specify there which pins are used for the switches.
I am using BBB with Hermes/Cronus reclocker and I2S output (no USB) to a DDDAC. Is there a way to get info from BBB or Hermes/Cronus to drive simple LED's to indicate 44.1, 88.2, 176.4, 48, 96, or 192 sample rate of the file I am playing? As a bonus, but not necessary, bit depth indication of 16 or 24 would be nice too.
Sorry if this was covered, I tried searching this topic but found nothing.
Thanks!
Sorry if this was covered, I tried searching this topic but found nothing.
Thanks!
Yes, this can be done. I do something similar but with text output rather than LED output. ...though I don't care about bit depth.
Steps include:
A. Make an LED driver circuit if the LEDs you want to use draw too much current for direct drive from GPIO pins. [This is probably the case.] I use a simple 8 channel driver chip - ULN2803 or similar.
B. Learn how to initialize and control GPIO pins. I suggest doing this in Python, though bash works too.
C. Write a simple program to sense the parameters and indicate the results. You are talking about 6 rates and two bit depths, or 8 LEDs. Is that satisfactory? Another option is to use RGB LEDs and display color rather than lots of on-off locations. If I2C is an option, you have more display choices.
I have Python code working for options B and C, and am happy to share.
Steps include:
A. Make an LED driver circuit if the LEDs you want to use draw too much current for direct drive from GPIO pins. [This is probably the case.] I use a simple 8 channel driver chip - ULN2803 or similar.
B. Learn how to initialize and control GPIO pins. I suggest doing this in Python, though bash works too.
C. Write a simple program to sense the parameters and indicate the results. You are talking about 6 rates and two bit depths, or 8 LEDs. Is that satisfactory? Another option is to use RGB LEDs and display color rather than lots of on-off locations. If I2C is an option, you have more display choices.
I have Python code working for options B and C, and am happy to share.
No problem. Since this is not specifically related to the kernel, meet me over at:
Control of BBB-based audio appliances
Frank
I know this might be annoying for some people but I think it’s still interesting and an add on to the compatibility of playback methods:
In this new thread, encoded surround audio is received optically and fed to BB by i2s. The BeagleBone encodes the audio and gives out multichannel i2s.
Surround decoder for encoded digital audio (AC3, DTS, AAC) with Beagle Bone Black
I it possible to integrate that on top of botic?
In this new thread, encoded surround audio is received optically and fed to BB by i2s. The BeagleBone encodes the audio and gives out multichannel i2s.
Surround decoder for encoded digital audio (AC3, DTS, AAC) with Beagle Bone Black
I it possible to integrate that on top of botic?
It could be done. If I remember correctly, Botic still won't accept SPDIF input. But you can get around that by using a SPDIF to USB converter and there are several that I know of that do a good job. Botic/ALSA can manage the multi-channel streams and output them on different I2S channels. For example, here is 'arecord -L' from my BBB:
Code:
sysdefault:CARD=miniStreamer
miniStreamer, USB Audio
Default Audio Device
front:CARD=miniStreamer,DEV=0
miniStreamer, USB Audio
Front speakers
surround21:CARD=miniStreamer,DEV=0
miniStreamer, USB Audio
2.1 Surround output to Front and Subwoofer speakers
surround40:CARD=miniStreamer,DEV=0
miniStreamer, USB Audio
4.0 Surround output to Front and Rear speakers
surround41:CARD=miniStreamer,DEV=0
miniStreamer, USB Audio
4.1 Surround output to Front, Rear and Subwoofer speakers
surround50:CARD=miniStreamer,DEV=0
miniStreamer, USB Audio
5.0 Surround output to Front, Center and Rear speakers
surround51:CARD=miniStreamer,DEV=0
miniStreamer, USB Audio
5.1 Surround output to Front, Center, Rear and Subwoofer speakers
surround71:CARD=miniStreamer,DEV=0
miniStreamer, USB Audio
7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
iec958:CARD=miniStreamer,DEV=0
miniStreamer, USB Audio
IEC958 (S/PDIF) Digital Audio Output
dmix:CARD=miniStreamer,DEV=0
miniStreamer, USB Audio
Direct sample mixing device
dsnoop:CARD=miniStreamer,DEV=0
miniStreamer, USB Audio
Direct sample snooping device
hw:CARD=miniStreamer,DEV=0
miniStreamer, USB Audio
Direct hardware device without any conversions
plughw:CARD=miniStreamer,DEV=0
miniStreamer, USB Audio
Hardware device with all software conversions
root@beaglebone:/#For this SPDIF->USB converter, the data source would be 'surround71:' from ALSA and the output would come from any of a few BBB program options for piping I2S out to Cronus. The I2S data could be 'as good as it gets', considering the signal source. However, the pipe programs may lock the sample rate rather than adapt if the stream changes frequency. You could adjust them manually. I believe that the snd_aloop module for ALSA can bypass the frequency restrictions of, for example 'aplay' or sox. I haven't needed to investigate that because all my SPDIF input is one frequency. Latency can be a deal-breaker for video sources. As a pipe and I2S renderer, the BBB can function well within the constraints of acceptable 'lip-synch'.
In my book, 7.1 surround is an interesting standard, is OK with video, but not meant for serious music reproduction because of the extreme phase and sampling issues.
Cheers,
Frank