• Disclaimer: This Vendor's Forum is a paid-for commercial area. Unlike the rest of diyAudio, the Vendor has complete control of what may or may not be posted in this forum. If you wish to discuss technical matters outside the bounds of what is permitted by the Vendor, please use the non-commercial areas of diyAudio to do so.

Support for Botic Linux driver

Miero, hi!
Just downloaded your 4.8 kernel and it FINALLY understands where's mmcblk0 and where's 1, thank you. The older 4.5 always took the default one as 0 and that scrambled the bootloader heavily.

Now some questions. Is cpu freq set to maximum? I cannot find the governor.

Can powersave blob be loaded? I'd love to put bone into mem mode when unused. Guess I'm not the only one, so it's a nice idea to have a deb for everyone. Linux Core Power Management User's Guide (v4.1) - Texas Instruments Wiki

Thank you for your GREAT job!!!
 
Last edited:
No luck, that's not what I want. OK, will build the kernel myself, no prob.

One more piece of pain is volume control. Whilst I can invoke some hooks from, say upmpdcli, player daemon to tell the value to the DAC and read it back, I am not sure that the same can be done from within your driver. As I saw somewhere in the topic, there is i2c iface to the Sabre chip, but it cannot change the volume from outside, right? Or can it?

Sorry for being that annoying; it's enough just to poke me around the nearest page where it's been discussed. Cuz it must have been.
 
Member
Joined 2007
Paid Member
Are there ANY BBB players that will refer it's volume setting only to the DAC via i2c rather than invoking it's own lower-resolution computations within the i2s stream? :confused: I don't know of any, hence I have a separate DAC control setup on the same peripheral device that controls the player software.
 
Are there ANY BBB players that will refer it's volume setting only to the DAC via i2c rather than invoking it's own lower-resolution computations within the i2s stream? :confused: I don't know of any, hence I have a separate DAC control setup on the same peripheral device that controls the player software.
If this comment is addressed to me, let me clarify.
I'm building a rather universal renderer for my DAC. Currently the DAC core can be controlled from the front panel MCU only (knob, buttons, IR), as the renderer is an option. And the MCU can communicate with the Bone, I dedicated an UART for this.
The upmpdcli daemon, as I stated above, can execute some script/binary on volume change, AND on volume request (it checks the value periodically), so I wrote a simple program that stores the value in shared memory and updates it after the volume in the MCU (knob, IR) was modified, or after it's been modified in the daemon (using a slider in the control point app). This is quite simple and usable approach.
But.
But There is roon now... Afaik it communicates with the sound driver ONLY, no external hooks.
This is pain in terms of programming (I suspect I would need to learn writing snd_soc_xx modules) yet must be more universal of course.
Still I'm looking for a more simple way - miracles happen sometimes... :p
 
Member
Joined 2007
Paid Member
My question/comment was motivated by this experience. With es9018 DAC chips, I could hear a reproducible quality difference between a) level attenuation (at 40 bits) by the DAC on a full-volume I2S feed versus b) any level attenuation incorporated into I2S by the BBB (via player controls or in ALSA directly). Especially at lower outputs, the DAC did a better job at volume control providing more clarity and natural detail. Thus, for me, the small inconvenience of having a direct-to-DAC I2C control screen that is separate from the player's I2S-mediated volume control was more than compensated by improved fidelity and enjoyment. I have not tested this with Roon's built-in volume control - maybe it is better than the MPD variants I've tried.

I'm in the process of getting the new generation ESS DAC chips up and running. With them I expect the same (or greater?) sound benefit via I2C control of DAC volume on a full-volume I2S input signal.
 
Hey guys found this link via the Volumio forums. It provides the ability to build the latest Volumio for BBB with Botic and a few other things included. I'm on a Mac and not sure how to build it. I've tried using Homebrew to download a bunch of the dependencies, but have come up short. Maybe Fink will work. Anyone want to walk me thru the process if you've done it on a Mac? Or am I better off using a VM of Ubuntu to build it?

Here's a link...

GitHub - Tigor888/Volumio_BBB: Volumio on BeagleBoneBlack. This make work Image !!!
 
Member
Joined 2007
Paid Member
I ended up figuring it out with a Ubuntu VM...

The process was to:
"apt-get install" all the dependencies first
Then sudo ./build.sh the build folder with the switches.

The only thing I'm not sure about is which architecture is used for the BBB. My gut tells me armv7. I'll "bake my Pi" - beagle rather, and see if it works.
 
Ok... so these are my findings...

I needed to use Debian Jessie as my host system when building my image. When I used Debian Stretch or the Ubuntu 16.04.4 none of my builds would work. Just figured I'd offer this information to those who might not be well versed in all things Linux. Maybe someone who understands this stuff better could explain why using one version of Linux vs. another would make a build work or not. My guess is the host system has to have specific versions of software to make the build work and an updated or new OS is going to have newer versions that might not be compatible.
 
@miero nope they only offer it as a build it yourself.

I got the image to work after only using Debian Jessie VM. Stretch and Ubuntu don't build it correctly.

The only weird thing that I found when building the image was that the ssh service wasn't starting on boot. I had to use the serial interface to login and enable the ssh service.

sudo systemctl enable ssh.service

On a side note:
I never ended up using the BBE because I'm not sure how to make a special dtb - specifically for the BBE and the botic driver in mind.
 
Hi Miero and everyone,
yes unfortunately we had to make the choice to drop "official" support of some platform to best focus the effort of the core Volumio team to the main platforms (x86 and pi), also because we were always postponing releases of BBB images leaving them quite behind.

So, we set up a community porting version, in order to improve such situation by leveraging community support for those platform (our build system allows everyone to build a volumio image for any platform supported, and to be easily expanded to support new ones).

Hope this will bring the deserved attention to BBB, you can see the forum announcement here:
Volumio Community Support : Community portings

Of course, if there's any help needed just feel free to ask me!