I agree, specially as I already have 2 BBBs!
The main advantage I see with the Cubi would be if it can produce bitperfect I2S - this may end up as a cheaper overall option to a BBB plus cape.
OTOH in its simplicity the BBB is the cutest of the boards out there
I agree, specially as I already have 2 BBBs QUOTE]
Show Off!
You may be right ref overall cost though. In the end I don't care what it costs, it'll be a dang sight cheaper than a comparable retail streaming product.
This is good news! I feel a BBB cape with clocking options (separate power in and MCLK in and out ufl) would be very popular. I'd be in for at least 3. Maybe something that also has .1" headers to go to a Pi ect too. A little planning an the cape may fit atop the BBB and below the Pi?
Just to report a bit of experience with RPi+ Volumio.
The sound is very good and the installation was almost straight forward. There are some pops when there is track changes that are annoying, mainly if the output of the DAC goes straight to the amp.
It would be wonderful to have a connection between the RPi and the DAC via I2C so it would be possible to change the volume in the DAC and tune other parameters.
Also sometimes the services are not very stable and I don't really understand why. The web interface is sometimes not available (the server answer, but nothing is displayed). In these cases restarting the mpd server make it work, but not 100% of the times.
I had a bit of struggles mounting the shares, mount.cifs was not installed in the distribution I had, so I had to install it manually. I still did not manage to mount the share of the Apple Timecapsule.
Also a system based on this card has to be thought nicely, as I am not sure how happy on the long run the system would be to never have a clean shutdown.
In my other DAC the arduino is always on and takes care af switching on and off all the rest with some relais. It also mute the system during the power on and off. This is a nice feature, I'll try to port it on the RPi based system.
D.
The sound is very good and the installation was almost straight forward. There are some pops when there is track changes that are annoying, mainly if the output of the DAC goes straight to the amp.
It would be wonderful to have a connection between the RPi and the DAC via I2C so it would be possible to change the volume in the DAC and tune other parameters.
Also sometimes the services are not very stable and I don't really understand why. The web interface is sometimes not available (the server answer, but nothing is displayed). In these cases restarting the mpd server make it work, but not 100% of the times.
I had a bit of struggles mounting the shares, mount.cifs was not installed in the distribution I had, so I had to install it manually. I still did not manage to mount the share of the Apple Timecapsule.
Also a system based on this card has to be thought nicely, as I am not sure how happy on the long run the system would be to never have a clean shutdown.
In my other DAC the arduino is always on and takes care af switching on and off all the rest with some relais. It also mute the system during the power on and off. This is a nice feature, I'll try to port it on the RPi based system.
D.
Pin mapping for BBB (shared with HDMI output):
P9_25 - A14/0 - mcasp0_ahclkx (oscillator) - GPIO3_21
P9_31 - A13/0 - mcaps0_aclkx (bit clock) - SPI1_SCLK
P9_29 - B13/0 - mcasp0_fsx (lr clock) - SPI1_D0
P9_28 - C12/2 - mcasp0_axr2 (data1) - SPI1_CS0
More PCM outputs for multichannel:
P9_27 - C13/2 - mcasp0_axr3 (data2) - GPIO3_19
P9_30 - D12/0 - mcasp0_axr0 (data3) - SPI1_D1
P9_41 - D13/0 - mcasp0_axr1 (data4) - GPIO3_20 shared pin with D14
Onboard oscillator routed at GPIO3_21 is controlled by GPIO1_27.
This GPIO1_27 is in the Angstorm asserted from BB-BONELT-HDMI cape DTS file.
Without warranty, someone shall re-check this!
P9_25 - A14/0 - mcasp0_ahclkx (oscillator) - GPIO3_21
P9_31 - A13/0 - mcaps0_aclkx (bit clock) - SPI1_SCLK
P9_29 - B13/0 - mcasp0_fsx (lr clock) - SPI1_D0
P9_28 - C12/2 - mcasp0_axr2 (data1) - SPI1_CS0
More PCM outputs for multichannel:
P9_27 - C13/2 - mcasp0_axr3 (data2) - GPIO3_19
P9_30 - D12/0 - mcasp0_axr0 (data3) - SPI1_D1
P9_41 - D13/0 - mcasp0_axr1 (data4) - GPIO3_20 shared pin with D14
Onboard oscillator routed at GPIO3_21 is controlled by GPIO1_27.
This GPIO1_27 is in the Angstorm asserted from BB-BONELT-HDMI cape DTS file.
Without warranty, someone shall re-check this!
I've compiled info how to control onboard oscillator on Angstrom without recompiling kernel, just by changing device tree files -- http://bbb.ieero.com/
The procedure is quite complicated and requires patching and compiling DTS and booting BBB with alternative kernel command line.
Currently this is usable only if one has external 24.576MHz oscillator.
And also for fun if you want to stop the music...
For frequencies other than 48kHz new kernel will be needed.
The procedure is quite complicated and requires patching and compiling DTS and booting BBB with alternative kernel command line.
Currently this is usable only if one has external 24.576MHz oscillator.
And also for fun if you want to stop the music...
For frequencies other than 48kHz new kernel will be needed.
The serial adapter is needed, because I did not wanted to permanently modify eMMC. If the presented solution works with U-boot, one can replace uEnv.txt by uEnv-hdmix.txt (but keep the backup).
With this change the BBB will start with enabled control for onboard clock.
In case the BBB will not boot the serial console is required to skip loading uEnv.txt.
With this change the BBB will start with enabled control for onboard clock.
In case the BBB will not boot the serial console is required to skip loading uEnv.txt.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.