Hi. I'm confused too, the Botic driver will still re-sample, no way of forcing it to play native rates, even when using the external clocks?
Thanks.
Hi miero, and thanks for the ongoing development work you're progressing.
Just to double-check my understanding, you're next distribution release will enable the preservation of native sampling rates on the BBB through the use of the two external clocks. Currently it is using the BBB's onboard clock so the BBB is resampling 44.1KHz to 48KHz.
Cheers
Ray
Just to double-check my understanding, you're next distribution release will enable the preservation of native sampling rates on the BBB through the use of the two external clocks. Currently it is using the BBB's onboard clock so the BBB is resampling 44.1KHz to 48KHz.
Cheers
Ray
nautibuoy: I've never said that the "preservation of native sampling rates" is missing in the current driver. So it will not be added into the next release. In the manual you can find how to configure it.
The new feature in the next release will be arbitrary sample rate (e.g. 312.5kHz) for playback & capture.
The new feature in the next release will be arbitrary sample rate (e.g. 312.5kHz) for playback & capture.
Problem with MPD-0.18.17
Hi there,
MPD-0.18.17, which I recently compiled, works well with PCM sources but can not play DSD sources with Botic drivers.
Glancing at /proc/asound/card0/pcm0p/sub0#/hw_params, the culprit appears to be the fixed format of S24_3LE as shown below:
access: RW_INTERLEAVED
format: S24_3LE
subformat: STD
channels: 2
rate: 705600 (705600/1)
period_size: 1285
buffer_size: 21845
With the older version of such an MPD-0.18.16, the result should be expected like below:
access: RW_INTERLEAVED
format: DSD_U8
subformat: STD
channels: 2
rate: 705600 (705600/1)
period_size: 512
buffer_size: 65536
Editing /etc/mpd.conf have no effect on trying to change S24_3LE to DSD_U8.
Any idea, anyone?
TIA
Hi there,
MPD-0.18.17, which I recently compiled, works well with PCM sources but can not play DSD sources with Botic drivers.
Glancing at /proc/asound/card0/pcm0p/sub0#/hw_params, the culprit appears to be the fixed format of S24_3LE as shown below:
access: RW_INTERLEAVED
format: S24_3LE
subformat: STD
channels: 2
rate: 705600 (705600/1)
period_size: 1285
buffer_size: 21845
With the older version of such an MPD-0.18.16, the result should be expected like below:
access: RW_INTERLEAVED
format: DSD_U8
subformat: STD
channels: 2
rate: 705600 (705600/1)
period_size: 512
buffer_size: 65536
Editing /etc/mpd.conf have no effect on trying to change S24_3LE to DSD_U8.
Any idea, anyone?
TIA
Well, this does not work. Trying to compile this version always get errors like below:
mpd-dsd-018-master: In function ‘snd_pcm_format_t get_bitformat(SampleFormat)’:
src/output/AlsaOutputPlugin.cxx:301:10: error: ‘SND_PCM_FORMAT_DSD_U32_LE’ was not declared in this scope
make[1]: *** [src/output/liboutput_plugins_a-AlsaOutputPlugin.o] Error 1
make[1]: Leaving directory `/usr/src/mpd-dsd-018-master'
make: *** [all] Error 2
SND_PCM_FORMAT_DSD_U32_LE appears to be intended to support XMOS but this is not the case with Botic.
BTW, commneting ‘SND_PCM_FORMAT_DSD_U32_LE’ in src/output/AlsaOutputPlugin.cxx can complete to compile the source but the binary does not work with DSD as written before.
You are quite right. I tried new MPD version just for fun and now retreated back to the older, stable version.
Thanks for your quick replies.
Hi Chanh,
I presume that you watched our brief converesation. You would have no need to upgrade MPD to the latest version. Stay there until miero suggests a new instruction in the future.
Sorry about that. Indeed needs a newer/patched version of the ALSA lib. I'll see if I can build in a compile time check to disable DSD_U32_LE usage when not available.
OK, I've read the whole thread. I have a BBB in my hand. And I'm not 100% sure what to do next, so I'd like to ask for help.
I'd like to pipe Standard I2S (as opposed to Left Justified) into a PCM1794. No need for I2C.
I think this is the proper pinout:
P9_31 - BCLK
P9_29 - LRCK
P9_30 - DATA
Please correct me if this is wrong.
I also think I am clear that by default, the driver will use the clock on the BBB, which is fixed, and capable of producing the 48, 96, and 192kHz frequencies.... but will resample to playback 44.1 (etc.) Is this right? (I have no external clock at this time.)
Now, if you would refrain from laughing, I am stuck here. Assuming I *wanted* to change a parameter... how is this accomplished:
In which file are these set? I found very little useful info when searching how to set kernel options.
Thank you everyone for your support, and a special thanks to the folks who dedicate so much of their life energy solving the issues guys like me can't.
I'd like to pipe Standard I2S (as opposed to Left Justified) into a PCM1794. No need for I2C.
I think this is the proper pinout:
P9_31 - BCLK
P9_29 - LRCK
P9_30 - DATA
Please correct me if this is wrong.
I also think I am clear that by default, the driver will use the clock on the BBB, which is fixed, and capable of producing the 48, 96, and 192kHz frequencies.... but will resample to playback 44.1 (etc.) Is this right? (I have no external clock at this time.)
Now, if you would refrain from laughing, I am stuck here. Assuming I *wanted* to change a parameter... how is this accomplished:
In which file are these set? I found very little useful info when searching how to set kernel options.
Thank you everyone for your support, and a special thanks to the folks who dedicate so much of their life energy solving the issues guys like me can't.
The botic driver options can be set in the uEnvt.txt file in /boot/uboot/
Code:
##Disable usage of external Botic clocks
optargs=coherent_pool=1M snd_soc_botic.ext_masterclk=1musicapristina: you need to have linux image with Botic driver flashed on the SD card and BBB booted from it
then with your configuration it could work without any further settings of the uEnv.txt
Notice:
1) you need to connect also GND between DAC and BBB
2) I do not recommend to use direct I2S connection between DAC and BBB => this connection does not provide necessary protection to BBB. You should wait until cape will be ready, otherwise be prepared that BBB might be destroyed with some low probability.
then with your configuration it could work without any further settings of the uEnv.txt
Notice:
1) you need to connect also GND between DAC and BBB
2) I do not recommend to use direct I2S connection between DAC and BBB => this connection does not provide necessary protection to BBB. You should wait until cape will be ready, otherwise be prepared that BBB might be destroyed with some low probability.
Additional suggestion - use a case for the BBB. Mine was running well, but I accidentally zapped it with ESD merely by pushing the power button with my finger. [The heated air is dry here and static is generated easily.]
Miero, I assume it would help, when using a direct connection, to power the DAC separately and make sure the BBB is first-on, last-off. True?
Frank
Yes, that's what I am doing now.
Another (poor man) option would be power DAC from the 3.3V rail of BBB, but there is only 100mA available and when more is used then eMMC or SD card will start reporting errors (and write bad data).
The second best alternative after having the cape is to use P9_14 to control power switch for DAC. This is what I'm currently trying to prepare using N-MOSFET and fast relay. But this will work well only for good power shut down, if driver will be able to shut down the switch and wait long enough until DAC will be powered down.
The next driver release will contain configurable time between pulling down the P9_14 and powering the BBB down.