• 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

Member
2011-06-04 11:58 am
Prague
Last edited by a moderator:

miero

Member
2011-06-04 11:58 am
Prague
Version 1.0

Currently supported features:
- I2S up to 192kHz/32bit
- DSD64 and DSD128
- 2 to 8 channels

Questionable:
- MPD playback quality ... better to use command line tool play

Not yet ready/working:
- higher bitrates 352.8 and 384kHz ... starts but halts after while
- I2C control for ES9018
 

miero

Member
2011-06-04 11:58 am
Prague
power down support

The distribution has integrated support for automatic shutdown of BBB after pressing POWER button.

Use it and wait while LEDs are on!

If that fails (more than 30 seconds), hold POWER button for 8 seconds.

I've already damaged one BBB while removing power cable from the connector while it was on.
 
Last edited:
Hi Miero,

Thanks again for all of this fine work for our community. I'd like to load your latest driver onto the BBB I purchased for this project, but I'm not sure that makes sense without a Botic. Is it possible to use the I2S channels directly into my BII without a Botic for checking the software operation?

- David
 

miero

Member
2011-06-04 11:58 am
Prague
Yes it is possible (I also don't have the cape), but:
- native playback only for 48k family frequencies
- the pins for I2S must be located in the P9 connector on BBB
- I2S output is not clean; the ES9018 must be set to maximum DPLL
- 44.1k frequencies must be resampled
-- at lower quality internaly on BBB via MPD
-- 44.1k->48k at max quality from command line on BBB via: play FILE rate -v 48k
-- or externaly using Linux machine ... the highest mastering quality is possible with just regular PC ... search doc for bbbplay command

I'd say it's worth a try if you have time. But if you want to be safe on the safe side, wait for cape... :)
 
Miero, the one driver that assumes external clocking, it will toggle the pin on the BBB to indicate what clock to use? So that if we have a device that has two clocks and a select pin, this could drive the selection on the device? I think I understand that's what the external clock driver is doing, but just want to verify. Thanks.
 

miero

Member
2011-06-04 11:58 am
Prague
Firstly, you need to edit uEnv.txt on the first partition if you want to enable external clocks (it is editable from windows too, but you need better editor than notepad, e.g. PSPad) . Currently there is snd_soc_botic.ext_masterclk=0 ... which is good just for BBB without external clocks. In this case frequency 44.1kHz and its multiples are not supported by driver.

Having a cape with 2 clocks (22.5792MHz and 24.576MHz) this value must be set to 3 or another alternative is 7 (3+4) if you want different polarity of the clock switch. Using this you declare support for 44.1kHz and also 48kHz data rates.

Before start of playback the driver sets the external clock switch to position according the requested frequency. The switch is not changed after stream ends. Just at the start of next stream only if different clock is needed.

The external clock switch just changes voltage on the pin P9_24: 0V or 3.3V.

Notice: Similar situation is with the I2S/DSD format switch that is on the pin P9_26.
 
Last edited:
Thanks Miero. Another question that will show my ingorance...:eek: .

When the BBB is using external clocks (i.e., a cape) its output is i2s signals including the mck from the selected external clock? So as input the BBB will be getting the MCK from the cape and generating i2s signals with bck/fsck/mck/data as output? Or the BBB is only providing bck/fsck/data to the cape and the cape does the clocking (the clock selected by the BBB driver)?
 

miero

Member
2011-06-04 11:58 am
Prague
No, audio chip at BBB is always configured to receive MCLK externaly.

If the cape is not present then the low-quality "external onboard BBB" 24.576MHz clock is used. This MCLK signal is in this case available on P9_25 pin.

If you enable external cape, then that "external onboard BBB" clock is automatically disabled by driver and the MCLK signal from "external cape" clock/s incoming via P9_25 pin will be used instead.

So the P9_25 pin is used as MCLK output when cape is not present, and as MCLK input if the cape is installed.
 
Last edited:
Well I followed the instructions but getting no sound.

I had previously set up the BBB with connections to a 9023 DAC using the earlier Botic drivers on Debian using Squeezelite - that worked and continues to work after rebooting on that SD card (eMMC actually).

Tried the new .img using both MPD and squeezelite but no audio. Squeezelite clearly sees the BOTICAudio device and looks like it is playing but no sound. MPD seems happy enough playing one of the test files but still no sound.

Anybody else have this working? Could it be this is now 9018 specific?
 

twluke

Member
2012-11-17 1:23 am
Tokyo
Thanks for the new botic driver

Hi miero,

Thank you for opening this thread for the botic driver support and also for providing us the latest SD image with the new drivers.

After spending some hours for auditioning with this 3.15.1-botic1 kernel system, I'd like to report my experience with it, referring to your instruction and comments on the page from http://bbb.ieero.com/.

> The distribution has integrated support for automatic shutdown of BBB

I enjoyed this. Thanks for this beautiful tweak. I also have my own history of damaging BBB a few month ago. ;-)

> By default the file is resampled if 44k1Hz frequency or multiples is being played. This might/will introduce hearable artifacts.

I confirmed it. After applying external clocks, playing the test_44k1_16b.flac file via MPD, that was heard with musicality under the built-in clock, became quite noisy and this was the case with all of my Red Book sources. Is there any way to avoid this problem?

> 1) using web MPC interface

The MPC interface is well designed and easy to use for a quick glance at the files.

> play FILENAME

The play command worked well and was more flexible in dealing with 44.1k sources than MPD in terms of noise-free play-back.

> 3) remotely form another linux machine by bbbplay

I enjoyed this hacking via a remote linux machine operating virtually on my Mac but how can I avoid entering my password requested by the BBB server before playing music?

> Notice: it does not support DSD

I hope this will be supported in the future.

> Installed clocks are configurable via:
- kernel option snd_soc_botic.ext_masterclk

For the temporary external clocks, I used either Amanero Combo384 DDC or I2SoverUSB DDC from jlsounds, both having MCLK outputs of 22.5792 and 24.5760 MHz, setting snd_soc_botic.ext_masterclk to 3. With this condition, I confirmed the sound files were played with its original SR.

> DSD format can be enabled via:
- kernel option snd_soc_botic.dsd_format_switch

First with this setting enabled, I failed to play the test DSD files provided under the /data, which caused severe signal drops, unable to complete the sequence.

However, to my surprise, the same setting went quite well with my personal collection of DSD sources, mostly DSD128 recorded from old vinyls, and, IMHO, the current botic driver appears quite well designed for this particular setting, that appears far superior to playing DSD by MPD with BBB connected to USB-DDC.

> The BBB has 4 serializers and each one is capable to generate:
- one stereo I2S channel
- one mono DSD channel

Here is a problem for me. By default playing PCM requires the LRCK pin to P9_29 header and the same pin must be moved to P9_41 header for 2-channel playing of DSD. I may be wrong with this understanding, but, if not, is there any way to move back and forth on the fly between these formats?

Anyway, I'd like to thank you, miero, for your great work. Cheers.

twluke
 

miero

Member
2011-06-04 11:58 am
Prague
ChrisMmm, with new driver you need to use different data pin (P9_30), or set kernel option snd_soc_davinci.sermask=4 ... or 12 if you want 2ch DSD too.

twluke, lrck position is fixed on BBB. The Botic cape will remap/route pins to correct positions. That's why there is I2S/DSD format switch pin.
 
ChrisMmm, with new driver you need to use different data pin (P9_30), or set kernel option snd_soc_davinci.sermask=4 ... or 12 if you want 2ch DSD too.

twluke, lrck position is fixed on BBB. The Botic cape will remap/route pins to correct positions. That's why there is I2S/DSD format switch pin.

OK, thanks, didn't read closely enough. Will try that.
 
ChrisMmm, with new driver you need to use different data pin (P9_30), or set kernel option snd_soc_davinci.sermask=4 ... or 12 if you want 2ch DSD too.

All good. Moved the pin on my I2S wiring harness. Tried MPD and test files first - all fine. Installed Squeezlite and tested - all fine. Haven't listened at length but my impression is I would be hard put to tell the difference between the BBB/Botic/I2S/ES9023 setup (with its re-sampling 44.1 to 48k) against my usual BBB/USB/ES9023 setup. This is great news, cant wait for the Cape!

Great work Miero.
 
miero:

> twluke, lrck position is fixed on BBB. The Botic cape will remap/route pins to correct positions. That's why there is I2S/DSD format switch pin.

Thanks for this info. As I'm not familiar with GPIO setting, I set up a 2-pole switch to alternate the connection from P9_29 and P9_41 to the main LRCK line toward the BIIISE via Teleporter. Things worked well for now.

However, here is one question. With the default channel configuration (-1), the sidedness of L-R channel on PCM is normal but is reversed on DSD play. Am I only one with this problem? I'll be happy if enlightened.

> Sorry, second command is ssh-copy-id

Thanks for this update. I'll try it later.

Regards,

twluke
 
Last edited: