Hi All, and excuse me for butting in with possibly a trivial question. Please also forgive me for not having read all 248 pages of previous posts before posting!
I have an application where I need to get audio into and out of a Beaglebone Black over either I2S or S/PDIF (on the software side the interface is ALSA). Is BOTIC the right way to achieve this?
What sources if information on BOTIC should I be looking at, and are there any other alternatives I should be considering?
I've been looking at this on-and-off for about 2 years and found lots of ideas but nothing, yet, that I could make into a workable solution... So thanks in advance for any information you can share.
I have an application where I need to get audio into and out of a Beaglebone Black over either I2S or S/PDIF (on the software side the interface is ALSA). Is BOTIC the right way to achieve this?
What sources if information on BOTIC should I be looking at, and are there any other alternatives I should be considering?
I've been looking at this on-and-off for about 2 years and found lots of ideas but nothing, yet, that I could make into a workable solution... So thanks in advance for any information you can share.
As far as I comprehend, Noticed allows the use of external clocks to clock the data, got to the first post and there is a web address ieero.com or the like, you need an external Cape, ala the twisted pear or ackodac SO3/4, the I2S data is then reclocked to the appropriate sample rate and buffered from the BBB so it isn't damaged from external sources.
I am no master at this so there areore experienced and knowledgeable.
I am no master at this so there areore experienced and knowledgeable.
tomi, if it would be acceptable for you can use it without cape utilizing the internal 48kHz fs compatible (and multiples) clock of BBB then you need to use just Botic kernel and configure it with following option:
snd_soc_botic.ext_masterclk=0
snd_soc_botic.serconfig=S--- (example configuration with output on P9_30)
List of all configuration option of Botic kernel you can find on http://bbb.ieero.com/
BTW, this single-clock scenario is possible also with non-Botic kernel, but the configuration must be done with custom device tree file
snd_soc_botic.ext_masterclk=0
snd_soc_botic.serconfig=S--- (example configuration with output on P9_30)
List of all configuration option of Botic kernel you can find on http://bbb.ieero.com/
BTW, this single-clock scenario is possible also with non-Botic kernel, but the configuration must be done with custom device tree file
Hi and thanks for the answers. I'm familiar with Linux as a user and a programmer, but I'm no expert on hacking the kernel, and the device tree is very new to me, so I've struggled to interpret some of the instructions I've found on the 'net while researching this problem.
To give more detail, I'm designing an instrumentation device which requires audio input/output, so the hardware is all custom - I'll not be using a clock-generating cape. My hardware expects to be I2S slave and 48kHz is fine, so no external clock should be necessary. That said, the hardware is not finalised and I could add one if required.
The hardware design also has the option of S/PDIF in stead of I2S. In some ways I would rather use S/PDIF as it is electrically more robust, but it depends what is easier to implement on the software side.
Thanks for the pointer to your website Miero - I had seen it, but had trouble knowing where to start. I think I'll have to try downloading and installing the Botic kernel and see what I have trouble with - and then come back with specific questions.
This is an impressive contribution to the community - thanks for all the time you've put into implementing and supporting it.
Tom.
To give more detail, I'm designing an instrumentation device which requires audio input/output, so the hardware is all custom - I'll not be using a clock-generating cape. My hardware expects to be I2S slave and 48kHz is fine, so no external clock should be necessary. That said, the hardware is not finalised and I could add one if required.
The hardware design also has the option of S/PDIF in stead of I2S. In some ways I would rather use S/PDIF as it is electrically more robust, but it depends what is easier to implement on the software side.
Thanks for the pointer to your website Miero - I had seen it, but had trouble knowing where to start. I think I'll have to try downloading and installing the Botic kernel and see what I have trouble with - and then come back with specific questions.
This is an impressive contribution to the community - thanks for all the time you've put into implementing and supporting it.
Tom.
It's making a bit more sense having read the website and the beginners HOWTO - incidentally, that HOWTO just shows up as garbage in my browser; I had to download it as plain test to make it readable.
If I understand correctly, input to the Beaglebone (eg, recording) is only possible in the I2S format - is that correct? So the Beaglebone won't receive S/PDIF, only transmit it.
I hope I'll get the chance to actually try some of this later in the week or over the weekend.
If I understand correctly, input to the Beaglebone (eg, recording) is only possible in the I2S format - is that correct? So the Beaglebone won't receive S/PDIF, only transmit it.
I hope I'll get the chance to actually try some of this later in the week or over the weekend.
Yes, the BBB is not capable to receive SPDIF. You would need to use SPDIF receiver that converts it to a compatible I2S signal.
I've found some strange issue with 4.8.13-botic7-rc3_1_armhf at bone-debian-9.4-iot-armhf-2018-06-17 (the same as with bone-debian-9.3-iot-armhf-2018-03-05) on BBB.
Here's what was done:
1. Installed on eMMC bone-debian-9.4-iot-armhf-2018-06-17
2. Installed 4.8.13-botic7-rc3
3. Added dtb=am335x-boneblack-botic.dtb to /boot/uEnv.txt
4. sync, reboot
After that I can't boot (log is attached).
Then I installed 4.8.13-botic7-rc3 on SD with debian-9.4-iot, modified /boot/uEnv.txt the same as as in the previous case and boot w/o any problem. But, it seems, I've booted from eMMC (some files was added before and I see them).
It looks like there is some mismatch between mmcblck0 and mmcblck1 in Stretch (with jessie there was no problems).
I'am quite novice in Linux and can't solve issue by myself. Perhaps someone had faced this problem before?
And I can confirm (cu6apum's post #2416), that it is needed to disable some capes to have sound with Botic .
In my case:
###Disable auto loading of virtual capes (emmc/video/wireless/adc)
#disable_uboot_overlay_emmc=1
disable_uboot_overlay_video=1
#disable_uboot_overlay_audio=1
disable_uboot_overlay_wireless=1
disable_uboot_overlay_adc=1
Here's what was done:
1. Installed on eMMC bone-debian-9.4-iot-armhf-2018-06-17
2. Installed 4.8.13-botic7-rc3
3. Added dtb=am335x-boneblack-botic.dtb to /boot/uEnv.txt
4. sync, reboot
After that I can't boot (log is attached).
Then I installed 4.8.13-botic7-rc3 on SD with debian-9.4-iot, modified /boot/uEnv.txt the same as as in the previous case and boot w/o any problem. But, it seems, I've booted from eMMC (some files was added before and I see them).
It looks like there is some mismatch between mmcblck0 and mmcblck1 in Stretch (with jessie there was no problems).
I'am quite novice in Linux and can't solve issue by myself. Perhaps someone had faced this problem before?
And I can confirm (cu6apum's post #2416), that it is needed to disable some capes to have sound with Botic .
In my case:
###Disable auto loading of virtual capes (emmc/video/wireless/adc)
#disable_uboot_overlay_emmc=1
disable_uboot_overlay_video=1
#disable_uboot_overlay_audio=1
disable_uboot_overlay_wireless=1
disable_uboot_overlay_adc=1
I have used a small hardware enhancement to enable my BBB to process S/PDIF. If the S/PDIF frequency is <=96kHz, the small converter board is only $35. It converts S/PDIF to asynchronous USB (or vice-versa). That USB input creates direct channels into ALSA, from which you would have many options for routing and processing directly by ALSA plugins, if desired.
Of course I don’t know many details about your application, and the overall role of the BBB, but if you need to make an I2S signal more robust then the Twisted Pear Audio Teleporter is a brilliant solution.
FYI, here is a link to my application of the S/PDIF -> USB converter board:
http://www.diyaudio.com/forums/twis...bbb-based-audio-appliances-5.html#post4680442
Best,
Frank
Vit123: it seems that existing Botic kernel is not compatible with new overlays loading from uboot. So... you need to use the older debian than 9.4 - but I'm not sure which one.
So ... I guess I really need to fix Botic kernel to be more up to date with current distros ... [I'm delaying this already for more than years...]
So ... I guess I really need to fix Botic kernel to be more up to date with current distros ... [I'm delaying this already for more than years...]
I'll recommend a Debian stretch kernel for BBB from here. The installation is quite simple if following the instruction. After that, you can install Botic system onto it.
Regards,
I think a lot of people will be grateful for that. 🙂
I use your kernel for BBB (as NAA) and iancanada McFIFO reclocker + Signalyst DSC v2 DAC in DSD512. It works perfectly! Even better then Advanced Amanero (with which artifacts sometimes appear) . 🙂
Thanks for advice, twluke.
Pls check my understanding:
1. Install bone-debian-9.4-iot-armhf-2018-06-17 on eMMC.
2. Boot from eMMC and install Debian Testing (buster) v4.14.44-ti-r51 kernel.
3. Reboot and install 4.8.13-botic7-rc3.
Is it correct order?
Correct.
Once confirmed that the bone-debian-9.4-iot-armhf-2018-06-17 on eMMC is working, use it to download the prebuilt debian stretch image (2018-06-08/elinux/debian-9.4-console-armhf-2018-06-08.tar.xz) as instructed and install the new system into an SD card via USB and confirm this SD card can boot normally. Then you can install the botic system into this working debian stretch on SD card. After confirmation of the system working, you can transfer the whole working Botic system into eMMC by editing /boot/uEnv.txt, if this is what you want.
BTW, my Botic system on debian stretch is well working as an NAA for HQ player to play DSD512 so beautifully on Buffalo 3SEpros (both 9028 and 9038).
Regards,
Hey guys,
could someone please share how are you resampling to DSD greater than 64?
I've tried using sox plugin in MPD, but with anything greater than DSD64 the sound came out with wrong speed.
Also, isn't DSD512 a bit too much for little BBB? 🙂
Thanks,
Fedor
could someone please share how are you resampling to DSD greater than 64?
I've tried using sox plugin in MPD, but with anything greater than DSD64 the sound came out with wrong speed.
Also, isn't DSD512 a bit too much for little BBB? 🙂
Thanks,
Fedor
Hi, Fedor.
I'm using HQPlayer for PCM-DSD512 online conversion, server is on ThreadRipper 1950X processor. BBB is only receives the stream and passes it to the DAC (NAA in term of HQPlayer design).
Best regards,
Vit.
twluke :
Confirm - it works great. Just prepared SD on my Linux desktop, booted BBB from SD, then moved image to eMMc by init-eMMC-flasher-v3.sh. No need to disable capes.
Many thanks!
Confirm - it works great. Just prepared SD on my Linux desktop, booted BBB from SD, then moved image to eMMc by init-eMMC-flasher-v3.sh. No need to disable capes.
Many thanks!
That's great. Quite happy to hear that. Now we are all the members of a club waiting for the release of the next Botic. 🙂