Hello miero,
My first post in this thread and to you.
Excellent job! Aweome. You solved everything needed in one driver and have thought about all possible scenarios for playback
Im running your image together with external clocks 22 and 24 and i2s reclocker. Tried with es9018, pcm1794, tda1543. Sounds excellent especially on pcm1794.
Im wondering. What is possibilities to force 2channel standard i2s data on all four data outputs? So basicly outputting exactly same data signal but on four outputs in sync?
Thanks!
BR
My first post in this thread and to you.
Excellent job! Aweome. You solved everything needed in one driver and have thought about all possible scenarios for playback
Im running your image together with external clocks 22 and 24 and i2s reclocker. Tried with es9018, pcm1794, tda1543. Sounds excellent especially on pcm1794.
Im wondering. What is possibilities to force 2channel standard i2s data on all four data outputs? So basicly outputting exactly same data signal but on four outputs in sync?
Thanks!
BR
It is definitely possible to do this - but it is far less expensive in terms of processing power to simply route one signal to all 4 of your DAC inputs.
You will be able to use higher sample rates this way.
It is definitely possible to do this - but it is far less expensive in terms of processing power to simply route one signal to all 4 of your DAC inputs.
You will be able to use higher sample rates this way.
I will not play with 4 dacs
Its for experimental reasons only...
I tried with MMMM setting. But maybe I should write IIII instead..?
I will not play with 4 dacs
Its for experimental reasons only...
I tried with MMMM setting. But maybe I should write IIII instead..?
I meant 4 inputs - not 4 DACs.
In any case have fun.You'd need to do a custom kernel, if inserting Botic, so dealing MPD versions shouldn't be too much more work. The ideal case would be a new beta release with the Botic driver built in, or if not reasonable (due to pinmuxing), possibly using a separate Botic image (same as base, just with the non-default device tree).
For easy set up, a distro like one of those two adding support would be the best option. As long as the file/stream sources are readily available on the network, both Runeaudio and Volumio can be set up and used with no exposure to the underlying OS at all.
FYI for the interested. I have the botic driver up-and-running on Fedora 21 (ARM). Hopefully the driver will be upstreamed so it becomes part of the stock kernel.
Yes, but IMHO it will take at least 2 iterations (from v3) until it will be more polished. In v4 it is better sepearated into generic configurable codec. But there are still DSD and channel mapping hacks in mcasp, which I think some will not like in the current (v4) state.
Thanks for the update, good to know.
After you release v4 I'll see if a can write a codec module for the AKM4490.
Do you have ideas how to (dynamically) get the various codecs to use your botic driver (so you can easily adapt to another connected DAC).
I am having a hard time cracking into the Linux audio world because it is so difficult to know exactly what all of the dependencies are... I am attracted to Volumio because of its working implementation of AirPlay [for rendering from "non-critical" sound appliances]. Volumio uses a non-standard MPD and I just found this recent documentation: https://media.readthedocs.org/pdf/volumio/latest/volumio.pdf
Is this version of MPD compatible with the Botic driver? ...and any specific advice on the compilation?
Is this version of MPD compatible with the Botic driver? ...and any specific advice on the compilation?
Reading the PDF you referenced to, Volumio seems to be plain MPD 0.18.9 only compiled with other options then the regular Debian version.
This version should work with the botic driver, at least for normal PCM. Native DSD support is limited in the stock MPD.
98.304 MHz clock
Hi miero,
With Botic BBB I've been long enjoying automatic external clock selection between 44K1 and 48K sources by applying a 2:1 MUX to P9_24 switch as indicated by your manual. The switch has been well working as well as the another one, P9_26, for I2S/DSD (I'm using 74HC157).
Recently I applied a 98.304 clock for 48K (Abracon, ABLNO-98.304) but it didn't work well. While the scope showed an expected frequency before loading, the actual speed of loaded music is very slow, as if the clock appears to be only working with a somewhat aliased lower frequency. Forcing BCLK/LRCLK ratio to 512(!) solves this problem but playing 44.1K sources is sacrificed instead.
The problem may be due to the limited accuracy of the oscillator or due to some flaw in my soldering including inadequate setting of decoupling cap. Or is there any possibility that this 98.304 MHz may be challenging the capability of Botic driver?
TIA
Hi miero,
With Botic BBB I've been long enjoying automatic external clock selection between 44K1 and 48K sources by applying a 2:1 MUX to P9_24 switch as indicated by your manual. The switch has been well working as well as the another one, P9_26, for I2S/DSD (I'm using 74HC157).
Recently I applied a 98.304 clock for 48K (Abracon, ABLNO-98.304) but it didn't work well. While the scope showed an expected frequency before loading, the actual speed of loaded music is very slow, as if the clock appears to be only working with a somewhat aliased lower frequency. Forcing BCLK/LRCLK ratio to 512(!) solves this problem but playing 44.1K sources is sacrificed instead.
The problem may be due to the limited accuracy of the oscillator or due to some flaw in my soldering including inadequate setting of decoupling cap. Or is there any possibility that this 98.304 MHz may be challenging the capability of Botic driver?
TIA
Hi twluke, I assume that BBB HW does not support such high frequencies.
Please check following document with timing and electrical requirements: http://www.ti.com/lit/pdf/SPRS717 pages 209-213.
Please check following document with timing and electrical requirements: http://www.ti.com/lit/pdf/SPRS717 pages 209-213.
Thanks for enlightening me. So it appears a timing issue of McASP[x]_ACLKR/X. BTW, is there any chance of software implementation for clock frequency divider for this matter in the future?
twluke
Last edited: