This firmware has a different URL - http: //pure.local
Or simply by the IP address obtained via DHCP.
By default (first start) mode is not selected. You have to choose HQP yourself through the firmware web interface.
Or simply by the IP address obtained via DHCP.
By default (first start) mode is not selected. You have to choose HQP yourself through the firmware web interface.
I have enabled IP on my PC and connected to PURE firmware.
I chose NAA (HQP) through the firmware web interface, but HQP still "didn't see" PURE like seeing Botic7.
I'm continuing to try .....
Many thanks to PPY
I chose NAA (HQP) through the firmware web interface, but HQP still "didn't see" PURE like seeing Botic7.
I'm continuing to try .....
Many thanks to PPY
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
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
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
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.
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:
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.
Different i2s modes doesn't help. MCLK is 45158400.
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
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? 😱🙄
Changing of the MCLK freqs in config file doesnt help. Beagle stop playing if they are wrong.
The issue anyway is in the acceptance of 64 or 32 bits.
The issue anyway is in the acceptance of 64 or 32 bits.
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.
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
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:
Hi, I believe you would need to change the blr_ratio parameter of the card module... This is set to 64 per default (stereo 2x32bits per sample) and should work with 48 for 2x24bits.
You can review miero's documentation here: http://bbb.ieero.com/
You can review miero's documentation here: http://bbb.ieero.com/
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:
Hi Frank
Thanks for the help, back in 2015 it was you that helped me get going with a startup script! just edited that script to include -a 24 -r 192000
after restart its working, is there a way to check the rate and format being output?
Many thanks Steve
Thanks for the help, back in 2015 it was you that helped me get going with a startup script! just edited that script to include -a 24 -r 192000
after restart its working, is there a way to check the rate and format being output?
Many thanks Steve
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.
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.
As I wrote above, blr_ratio work correctly only as 32 or 64.
Any other setting give unexpected LRCK frequency.
Any other setting give unexpected LRCK frequency.
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