• 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

Arch Linux ARM kernel updated to version 5.3.7

The linux kernel for Arch Linux ARM with botic patches on GitHub - coroner21/linux-am33xbot: Arch Linux ARM Kernel with botic patches was updated to version 5.3.7.

ATTENTION: Due to a major rework of the code of the machine driver (botic-card module), the driver in this repository currently only works for standard Cronus devices populated with two clocks and a GPIO switch to change frequencies. Configurations using the internal clock and accompanying it with an external clock for 44.1kHz frequencies currently do not work. Also using only one clock is currently not supported by the updated driver. If someone requires other configurations than the standard Cronus / Hermes boards let me know and I will enhance the driver again.

Please also read through the instructions on the github page regarding non-default clock frequencies. The device tree overlay needs to be edited in case frequencies other than the 49.152MHz / 45.1584MHz pair should be used.
 
Debian buster image available

Just to ensure that the debian users (with probably higher user base then Arch) also have a chance to use an updated kernel and the latest debian version: You can find a debian buster SD card (4GB) image here: Filebin

The link is valid one week. Please verify sha256sum:
Code:
6d85581559f2e95705d0057f4d6f3d86810286f22a5183d9cbf4d33cc74be928
This image was downloaded from bb.org today and includes only following modifications compared to the stock bb.org image:

  • kernel upgrade was installed (including botic patches for playback)
  • /boot/uEnv.txt was edited to enable the base BOTIC-00A0.dtbo overlay (i2s/dsd output, i2c control of any DAC connected to I2C bus 1 has to be done using scripts out of kernel space)
I tested sound output to a stereo DAC but nothing else. Since I do not use debian myself please check for yourself whether things are working alright.
 
Last edited:
Will it not be difficult for you to add these changes for mute to work correctly?
GitHub - luchoh/botic-dev at mute-v48


For me the way this is implemented looks like it is a simple GPIO switch to control a mute signal using one of the existing AXR pins of the McASP controller. I have to admit that I do not want to tinker so much with the McASP code especially since I do not use any mute signal myself (why is it necessary, what you want to achieve with it?)...


Anyways, I see that with the most recent McASP code it seems to be easily possible to use the McASP as a GPIO controller and several optional device tree bindings for this purpose have been added. Would it be possible to simply use this existing functionality?


In general I see that mute_stream / digital_mute seems to be implemented mainly for codecs rather than cpu DAIs. Would it make sense to specify a GPIO from McASP GPIO controller and use it in the codec to set it to HIGH / LOW for mute control?
 
Just to ensure that the debian users (with probably higher user base then Arch) also have a chance to use an updated kernel and the latest debian version: You can find a debian buster SD card (4GB) image here: Filebin

The link is valid one week. Please verify sha256sum:
Code:
6d85581559f2e95705d0057f4d6f3d86810286f22a5183d9cbf4d33cc74be928
This image was downloaded from bb.org today and includes only following modifications compared to the stock bb.org image:

  • kernel upgrade was installed (including botic patches for playback)
  • /boot/uEnv.txt was edited to enable the base BOTIC-00A0.dtbo overlay (i2s/dsd output, i2c control of any DAC connected to I2C bus 1 has to be done using scripts out of kernel space)
I tested sound output to a stereo DAC but nothing else. Since I do not use debian myself please check for yourself whether things are working alright.

Please clarify! Have You modified img bone-debian-10.0-iot-armhf-2019-07-07-4gb.img.xz ? Index of /images/
 
My DSC2 project is DSD-only DAC. No signal mute very loud clicks.
Therefore, in my mini firmware for BBB, I can only use the 4.X kernel version and this patch

I see that you use AXR3 / GPIO3_19 as mute pin. Rather than hacking the GPIO usage into the McASP module, it would be much more easy in your case to simply setup the McASP to use two serializers only (AXR0 / AXR1 as required for two DSD channels).

My suggestion would be then to integrate the mute rather in the generic BOTIC codec as an optional GPIO that is claimed in case it is configured in the device tree as part of the codec node (e.g. mute-gpios = <&gpio3 19 0>) and implement the digital_mute function as part of the snd_soc_dai_ops for the codec. If you are willing to test this, I can quickly add the required code to the Arch Linux ARM kernel and provide instructions. Unfortunately I have no way of testing it myself since the ESS DACs seem to do just fine even without any mute being applied.

Also in your case (since you know that you want to only support DSD sample formats) it might make sense to change the botic-codec definitions so that they only include DSD. That way you would not even need the DSD switch since ALSA would already error out.
 
Moode propose two variants 0.21.13 and 0.20.23.
I have heard that 0.20.23 sounds better!

If you believe in improved sound from different versions of MPD then just choose the version that sounds best. I do not really believe in such things and just choose the newest version.


By the way: Please do not query with same questions in PM and the public thread. Additionally, this thread should be kept as much as possible related to botic driver discussions in my opinion.
 
Last edited:
Hi coroner21, thanks for your great contribution.

Just to ensure that the debian users (with probably higher user base then Arch) also have a chance to use an updated kernel and the latest debian version: You can find a debian buster SD card (4GB) image here: Filebin

The URL above is now gone but I've successfully managed to download the image file before it and prepared a working SD card. Then I inserted it into the SD slot of BBB. After apt-get update and apt-get upgrade, I installed MPD, cifs-utils and networkaudiod, just founding the image has worked like a charm for MPD and as an NAA for HQ player.

uname -a: Linux beaglebone 4.19.73+ #1 SMP PREEMPT Tue Oct 22 15:10:29 CEST 2019 armv7l GNU/Linux

My B3SEpro is I2C-controlled and I confirmed it also worked well.

The problem for now is the system can only play DSD up to DSD256 on HQP and I couldn't manage to play DSD512 even after many trials of on-board clock settings on the Cronus.

access: RW_INTERLEAVED
format: DSD_U32_LE
subformat: STD
channels: 2
rate: 352800 (352800/1)
period_size: 4096
buffer_size: 16384

I'd like to appreciate any suggestions to solve this issue.

Again, thank you for your great work.

Regards,
 
I'd like to appreciate any suggestions to solve this issue.

Again, thank you for your great work.

Regards,


Happy to hear that it works.
Regarding DSD512: I believe that is a limitation in the sample rates specified in the patch for the McASP and Botic codec: They are limited to 384KHz / 352.8KHz max which means that with DSD U32 you get at most DSD256. Probably simply changing the sample rate limits would work to enable also DSD512, which I never tried since I do not really use such high rates.

I can update the kernel patches and rebuild the image. Not sure why the link is already down though. Anybody let me know the best free hoster to use for this purpose?
 


Thanks miero, I have seen these patches but they have not made any difference for my use cases (only have DSD64 files around) so I just removed the buffer increase from my patch set. I would assume that for stereo DSD512 it should still be fine without increasing the buffer? Maybe twluke can test and report back about the situation today. I found that this buffer increase leads to incredibly high ALSA buffer / period sizes and increases latency a lot.