• 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

5Mhz or 10Mhz clocks with BBB

Has anybody tested or know if the 5/6 Mhz clocks and 10/11 Mhz clocks will work fine with the Botic/BBB?

I use currently successfully 45Mhz and 22Mhz clock with my Botic/BBB and would like to test Andrea's new 5/6 Mhz clock but I have been told that maybe the BBB (or Botic) has some issues/limitation working with low frequency clocks (<22Mhz).

Can someone comment that? thanks!

Best regards
 
Member
Joined 2007
Paid Member
Has anybody tested or know if the 5/6 Mhz clocks and 10/11 Mhz clocks will work fine with the Botic/BBB?
<snip>
Can someone comment that? thanks!

This comment is *pure speculation* because I have not tested my BBB under those conditions. Given that caveat...

I suspect that the BBB and kernel would not function any differently regardless of the actual frequency of the clocks in Cronus or other reclock hardware. The slow-clock, of course, should produce less phase noise polluting the eventual I2S output. *If* that frequency must also serve as an external master clock to the DAC, then you must be sure it is sufficient. In the case of the ESS DACs, I could be wrong but I believe the 'true sync' firmware for Buffalo3 enables 128fs mode (Register 10 bit 4), which would require a minimum MCLK of 5.6448 MHz for redbook (44.1kHz) material. If you have typical HD PCM source material of up to 176.4/192kHz then the DAC will need a proportionally faster master - e.g. 22.5792/24.576 MHz - to use sync mode with 128fs.

In summary, I'm guessing the BBB doesn't care about the clock used by Cronus (or other reclock function) but believe that a Buffalo3 DAC programmed for synchronous use *does* care. Still, an ESS DAC should work in asynchronous (master) mode, but if you have an incredible oscillator, you want the DAC using it too, right?

When you test it, let us know if and how much that clock phase noise helps/hurts final output! :)

Frank
 
Many thanks, Frank, for your comment. I own a DDDAC (PCM1794, NOS) and there is of course no problem running it together with Botic/BBB with 45/49 Mhz (a friend of mine with 22/24Mhz) clocks. I do hope that the better phase noise characteristic of 5 Mhz clocks (just redbook format) reveals an audible improvement in sound quality and this is why I am interested to test it.

Unfortunately the SC-Cut Xtal shipment is delayed until June as Andrea has informed us. For sure I will let you know once the clock is ready and tested. However, I am not going to build Andrea's new oscillator (very large size ;) ) but go for his old Driscoll suggestion (TWTMC-D) and I hope it will work with 5Mhz fine as well :) .

Best regards
 
Hello,

I have two 18-bit PCM58 and use L/R data out from the latest Pure firmware.
PCM58 accept 18-bit word in MSB mode (+3 or +4 in config), otherwise it won't work.

Therefore I set snd_soc_botic.blr_ratio=36. The issue is: for 44100 file I see 44.8 kHz LRCK and 1.613 mHz BCLK from the BBB board.

It is all correct for default values of 32, 48 or 64, but the chip itself require 18 bits.

What can I do?

Thanks.

P.S. Whatever DAC I use, and even in a generic i2s mode – setting any other value for blr_ratio than 32-48-64 affect LRCK frequency to mismatch the file frequency.
 
Last edited:
Member
Joined 2007
Paid Member
What can I do?

P.S. Whatever DAC I use, and even in a generic i2s mode – setting any other value for blr_ratio than 32-48-64 affect LRCK frequency to mismatch the file frequency.

This is just one opinion, and I'm sorry I don't know of a simple solution to your problem. I suspect you need a different kernel, or you need some kind of post-processing to make the BBB output compatible with the old PCM58. Neither of those is an attractive project. Faced with those options, I personally would replace PCM58s with something that can accept a minimum of 24 bits. The reason is that the 8 bits between 16 and 24 are very much within the audible range, and (to my ear) provide about as much added resolution as doubling the sample rate.

Sorry not to be of more help.

Frank
 
Member
Joined 2007
Paid Member
I have noticed same for blr_ratio=48. Again here, 44.8 kHz LRCK frequency from the file of 44.1 kHz. Only 32 or 64 (default) ratio gives exact 44.1 kHz output.

Different i2s modes doesn't help. MCLK is 45158400.

I'm away from my BBB system and can't test this (possibly naive) idea, but what happens if you simply tweak the external master clock frequencies in the botic configuration file? Perhaps equal to 44.8/44.1*45158400? :eek::rolleyes:
 
I had a BBB-> Hermes-> Cronus-> ES9038PRO DAC configuration. Unfortunately, the DAC is broken. The new DAC does not need the features provided by Hermes-Cronus. But I want to recycle BBB and Pulsar clocks in a new frontend/streamer.
I'm looking for a BBB software image, capable to handle 44.1x and 48x external clock signals.
 
Squeezelite confg help needed

Hi all,

Can anyone please help a total Linux novice make sure Squeezelite on my BBB Hermes Cronus outputs 24bit 192 I2S so that I can convert to S/PDIF with the S/PDIF transceiver.

I managed to install Botic4 and Squeezelite in 2015 mostly by copy/paste instructions without really knowing what I was doing, but its worked perfectly since then.

I need to convert to S/PDIF and I think the reason I'm having trouble with the transceiver is that Squeezelite may be outputting 32 bit.

I can log into root Botic using PuTTY but after that I'm stuck!!

I have spent several hours searching the relevant forum topics without success

Some VERY basic help would be greatly appreciated.

Cheers Steve
 
Last edited:
Member
Joined 2007
Paid Member
Hi all,

Can anyone please help a total Linux novice make sure Squeezelite on my BBB Hermes Cronus outputs 24bit 192 I2S so that I can convert to S/PDIF with the S/PDIF transceiver.

I managed to install Botic4 and Squeezelite in 2015 mostly by copy/paste instructions without really knowing what I was doing, but its worked perfectly since then.

I need to convert to S/PDIF and I think the reason I'm having trouble with the transceiver is that Squeezelite may be outputting 32 bit.

I can log into root Botic using PuTTY but after that I'm stuck!!

I have spent several hours searching the relevant forum topics without success

Some VERY basic help would be greatly appreciated.

Cheers Steve

Hey Steve,

If Squeezelite is the only player you will be using then perhaps some of its options will do the trick.

The command line option -a allows you to select an output bit depth. Squeezelite has many command line options described here: Man page of SQUEEZELITE

You simply add options when you start the program running, like this:
‘Squeezelite -a 4096:1024:24:0’

Hint: it might also work to simply use ‘-f 24’, or ‘-a ::24:’ (depending on the version you are running - which you can check using ‘Squeezelite -?’)

Best,

Frank
 
Last edited:
Member
Joined 2007
Paid Member
Good, Steve, but I think the two colons between -a and 24 are likely important. As you can read in the manual page, there are multiple parameters set by -a and bit depth is the third of either 4 or 5. Buffer size of 4096 and period of 1024 are usually good. (I double both for my particular system. ) That is the rationale for the longer startup command - to avoid any lower quality defaults.

To answer your second question, yes! There is a text file several directories deep that reports current ALSA data stream. I’m away from my system for the time being and can’t look up the file path. Sorry. Perhaps it is in the docs from Meiro that Coroner21 cited above.
 
Good, Steve, but I think the two colons between -a and 24 are likely important. As you can read in the manual page, there are multiple parameters set by -a and bit depth is the third of either 4 or 5. Buffer size of 4096 and period of 1024 are usually good. (I double both for my particular system. ) That is the rationale for the longer startup command - to avoid any lower quality defaults.

To answer your second question, yes! There is a text file several directories deep that reports current ALSA data stream. I’m away from my system for the time being and can’t look up the file path. Sorry. Perhaps it is in the docs from Meiro that Coroner21 cited above.

Thanks Frank
I have changed it to -a 4096:1024:24:0 working fine, just need to check output, if an when you have time would you kindley post the path to the text file.
Cheers Steve
 
Member
Joined 2007
Paid Member
Thanks Frank
I have changed it to -a 4096:1024:24:0 working fine, just need to check output, if an when you have time would you kindley post the path to the text file.
Cheers Steve

I will be away from my system most of the summer but I was able to find it in some of my code on GitHub. The file name is ‘hw_params’ and it only exists with a signal running.

proc/asound/Botic/pcm0p/sub0/hw_params

All the best!

Frank