Hi everyone, I have been developing a 6-in 8-out RPi5 soundcard, and I am looking for people to test it. Please see this thread on ASR. You can DM me on this forum as well if you are interested.
Sounds interesting. It would be even more interesting if it had balanced in/out. 😎
Does is need RPi5, or would an RPi3 or RPi4 work, too?
Does is need RPi5, or would an RPi3 or RPi4 work, too?
The headers on the mainboard take differential inputs and outputs, so we could design an I/O board with differential connectors. Since the board is aimed more at value than performance, I figured single-ended would be more popular.
It needs RPi5 as earlier versions only have stereo I2S.
It needs RPi5 as earlier versions only have stereo I2S.
Bumping this thread as I have written up the project on hackaday here. If you put a Pi with this card, some amps and an SMPS in a chassis, you can create a DIY home theater/streaming system. Of course, you can also use it as the basis for all kinds of audio experimentation.
If anyone is interested in buying one, let me know.
If anyone is interested in buying one, let me know.
Stephen, thanks for the great work! It really surprises me that until now ASoC did not support the obvious scenario of one codec master and all remaining connected DAIs slave. The PCM3168A codec driver has been there for almost 10 years. How could it actually have been used the in master+slave mode? Maybe with a specific machine/card driver, not using the simple-card template?
Since you tested Kuninori's patch - please how do you configure the ext_fmt in the 6.14 simple-card overlay? A working overlay for the simple-card is always a pain for me. Thanks.
Since you tested Kuninori's patch - please how do you configure the ext_fmt in the 6.14 simple-card overlay? A working overlay for the simple-card is always a pain for me. Thanks.
@phofman - you don't configure ext_fmt explicitly. You just mark the clock producer and it will configure everything correctly. Note that simple-card only supports 1:1 relationship between CPU and codec, so it's not possible to configure this scenario. For DAIs with multiple codecs, you need to use audio-graph-card2.
I suspect that prior uses of PCM3168A were either having the codec as a clock consumer, or having separate RX and TX I2S clock pins on the CPU (meaning the codec ADC and DAC can both be clock producer). Here is an example of somebody using the PCM3168A on an IMX7 quite a while ago... if you go and look at the pinout on p47 of the board's datasheet, then you'll see that the SAI2 interface they're using has separate BCLK/FSYNC pins for RX/TX. The Pi just has one set, meaning you need to tie the codec's clocks together.
Happy to help writing overlays, just send me a diagram of your card.
I suspect that prior uses of PCM3168A were either having the codec as a clock consumer, or having separate RX and TX I2S clock pins on the CPU (meaning the codec ADC and DAC can both be clock producer). Here is an example of somebody using the PCM3168A on an IMX7 quite a while ago... if you go and look at the pinout on p47 of the board's datasheet, then you'll see that the SAI2 interface they're using has separate BCLK/FSYNC pins for RX/TX. The Pi just has one set, meaning you need to tie the codec's clocks together.
Happy to help writing overlays, just send me a diagram of your card.
Thanks, I slowly start to understand 🙂 Looking at places where the ext_fmt field is set - only in the graph card. That's because the simple-card does not need it due to its 1 cpu : 1 codec limitation.
IIUC in your overlay there are two DAI links (dailink_in_slave, dailink_out_master), both connected to the same CPU DAI &i2s_clk_consumer. Since such config yields codec master in both of the DAI links, you had to add a flag to PCM3168A to force override this (dac-force-cons, adc-force-cons).
Yes, that's standard. RPi has always been very limited in I2S features. And RPi5 does not even support the combinations SND_SOC_DAIFMT_CBP_CFC and SND_SOC_DAIFMT_CBC_CFP (these political renames master M -> producer P, slave S -> consumer C....)
Thanks for discussion.
Your understanding is exactly right. I tried to explain it in one of the project logs on hackaday (see above for link).
Is there a scenario where the producer of the bit clock isn't the producer of the frame clock? It seems strange ... I'd be interested if there's a scenario where it's needed. They buy the I2S peripheral design from Synopsys so perhaps that doesn't support those configs.
Recently a patchset was accepted to complete the renaming for all of ASoC (s/old/new/g for the constants). Personally I don't have any problem with it. Not sure if it was into 6.14 or 6.15.
Is there a scenario where the producer of the bit clock isn't the producer of the frame clock? It seems strange ... I'd be interested if there's a scenario where it's needed. They buy the I2S peripheral design from Synopsys so perhaps that doesn't support those configs.
Recently a patchset was accepted to complete the renaming for all of ASoC (s/old/new/g for the constants). Personally I don't have any problem with it. Not sure if it was into 6.14 or 6.15.
It's quite unusual indeed. I can imagine having bit clock generated from somewhere and asking the DAI to generate corresponding frame clock.
More useful DAI features are clock inversions (also not present in that Synopsys IP). RPi4 could run at 768kHz (as slave), but I had to invert the bit clock to account for the group delays in the internal circuits. But it was a hack...
I do not have a problem with naming in the code (gets compiled anyway), but changes to configuration are inconvenient. IIUC the old constants remain valid here. But I saw some projects which politically changed from master/slave, but had to keep these words in the config params to keep legacy config working. IMO waste of work...