|
Home | Forums | Rules | Articles | diyAudio Store | Blogs | Gallery | Wiki | Register | Donations | FAQ | Calendar | Search | Today's Posts | Mark Forums Read | Search |
Twisted Pear Superior quality electronic kits |
![]() |
|
Thread Tools | Search this Thread |
![]() |
#2921 |
diyAudio Member
|
I do not get this attitude... Why bother with DIY at all if it is too much effort? Just get a ready-made device running volumio like this volumio primo and be done with it.
|
![]() |
![]() |
#2922 |
diyAudio Member
|
![]()
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. |
![]() |
![]() |
#2923 |
diyAudio Member
Join Date: Jun 2011
Location: Prague
|
coroner21, thanks for maintaining this.
I suggest you to copy & update also the README file of the driver to the GIT repository: - http://bbb.ieero.com/botic5/README-botic5
__________________
BeagleBone Black with I2S, DSD and SPDIF interface (Linux driver) http://bbb.ieero.com/ |
![]() |
![]() |
#2924 |
diyAudio Member
|
![]()
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
Last edited by coroner21; 22nd October 2019 at 10:23 PM. |
![]() |
![]() |
#2925 | |
diyAudio Member
Join Date: Aug 2015
Location: Russia
|
Quote:
GitHub - luchoh/botic-dev at mute-v48 |
|
![]() |
![]() |
#2926 |
diyAudio Member
Join Date: Jan 2015
|
|
![]() |
![]() |
#2927 | |
diyAudio Member
|
Quote:
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? |
|
![]() |
![]() |
#2928 |
diyAudio Member
Join Date: Aug 2015
Location: Russia
|
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 |
![]() |
![]() |
#2929 | |
diyAudio Member
Join Date: Jan 2019
|
Quote:
|
|
![]() |
![]() |
#2930 | |
diyAudio Member
|
Quote:
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. |
|
![]() |
![]() |
Thread Tools | Search this Thread |
|
|
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
Open baffle with fullrange driver and bass support | Godzilla | Full Range | 5 | 22nd July 2011 02:32 PM |
Low end support for single driver monitors | strider75 | Multi-Way | 97 | 30th September 2009 04:02 PM |
ASIO support (driver) for Labview | Aoxomox | Digital Line Level | 0 | 3rd May 2009 06:29 PM |
Linux/BruteFIR support coming in LspCAD | tcpip | Multi-Way | 18 | 18th October 2005 04:08 AM |
linux | badgers | Introductions | 3 | 3rd April 2005 04:27 PM |
New To Site? | Need Help? |