As is, I would say it’s very Raspberry Pi related, the overlay especially. And I believe it must be associated To some kind of reference design.
M’y 2cts
I think our driver is very similar to the existing spdif_dit & spdif_dir drivers so it should be possible to request its inclusion upstream. I will have a go. The main difference is our addition of parameters to set the max audio channels which I believe its cousins would benefit from too.
2 Likes
Driver itself is quiet generic, so, yes, I guess pushing it upstream is doable. The overlay is RBPi and Zynthian specific, so maybe submitting it to Raspberry Pi kernel source is more accurate …
Some updates here:
I’ve managed to remove the C109 cap (using two soldering irons) and have tried to fix the track with a cutter. But still with no success yet …
Btw, RBPi will soon move to 6.12 kernel
Hi everyone, I have now updated this audio card to include most of @riban comments:
- left/right channels are now properly linked to jacks (not reversed).
- solder pads now include proper explanation what is their purpose.
- there are now solder jumpers to select data in and out i2s channels so 40pin connector can be used and cards can be stacked.
- there is now solder jumper to switch on/off crystal oscillator so that it can be disabled when card is in slave mode
- additional pin headers connectors are added for audio in and out so that the can be used instead of jacks for enclosures that need panel mounted jacks.
- VDD and AVDD are now supplied by two LDOs
- oscillator now include capacitors as per their technical documentation
Here is how card look like now:
Let me know your thoughts if something else could be done better so that I fix that before doing pull request to include this into zynthian-hw GitHub.
[EDIT] Here is schematics:
3 Likes
I see you are still presenting “I2S_MASTER_CLOCK” on RPi pin 7. This ties up this GPIO for no reason.
I would prefer none of the jumper pads be normalised but instead require manual soldering. It is easy to dab solder onto a pad, especially when you have to solder up the rest of the connectors. It is fairly easy to remove solder from a pad. It is more challenging to reliably and safely cut PCB tracks.
I see that you are disabling the X2 crystal oscilator by simply removing power but this leaves its output connected which may impact operation of other chips. There is a tri-state. It may be advantageous to offer the ability to completely remove it, e.g. by adding pads for its output.
I find the use of “I2S Master Clock” confusing. There isn’t really such a thing. There is a 24MHz clock that some chips use to sync and produce I2S data and clocks. It isn’t part of the I2S spec. Maybe remove “I2S” from its references. Maybe add 24MHz, e.g. “24MHz_Clock” or “24.576MHz_Clock”.
PCM1808 in slave mode cannot work without this “master clock”. Therefore when multiple cards are used this clock must be propagate to additional cards - hence I though to do it through pin 7. Maybe, I could expose a this as a dedicated pin on a board and not included in 40pin connector.
I agree, I have discovered too that you can damage PCB if you are not careful when cutting the connections on solder jumper.
I have added another solder jumper for output.
You are right - it should be called PCM1808 and PCM5102 internal chip clock. Even PCM5102 can work without it because it can utilise its own internal clock and sync it with BCK. I did not do that but I could simple disconnect this clock from PCM5102 and put ground instead that will trigger PCM5102 to produce its own internal clock. Then we can call this PCM1808 internal clock.
No, don’t do that. The PCM5102 can create the 24MHz clock it needs by using a phased lock loop, tuned by the bit clock but this has jitter and is suboptimal. It is a great feature that simplifies design of DAC boards but we have a master clock so should use it to lock everything together.
Ah yes, of course. We need to bind the stacked boards together. I would prefer it was not at the expense of a RPi GPIO but understand it simplifies design. I’m not sure what load we add to the RPi by stuffing 24MHz up its GPIO7.
No, don’t do that. The PCM5102 can create the 24MHz clock it needs by using a phased lock loop, tuned by the bit clock but this has jitter and is suboptimal. It is a great feature that simplifies design of DAC boards but we have a master clock so should use it to lock everything together.
Ah yes, of course. We need to bind the stacked boards together. I would prefer it was not at the expense of a RPi GPIO but understand it simplifies design. I’m not sure what load we add to the RPi by stuffing 24MHz up its GPIO7.
Here is the update design based on latest @riban comments:
- all solder jumpers are not connected so they will need to be connected by solder instead of having them with default connections that need to be cut if configuration need to be changed.
- I2S MASTER CLOCK is rename to INTERNAL CLOCK in schematics
- internal clock is decoupled from pin 7 using additional 2 pin header. That gives option for user to propagate internal clock either through pin 7 or with dedicated cable for stacked cards. If they want to propagate clock using pin 7 they need simple top put jumper on 2 pin header. If they want to propagate internal clock through using separate cable they can connect cabe to pin with name ocs.
- oscillator is now decoupled on both ends: power and output
- additional JST connector is added for connecting audio input and output to panel connectors.
Here is some of the screenshots:
1 Like
Would it be useful to put the input J connector onto the 1/4" jack default connections so you could still operate with either the default audio in from the J connector or an inserted jack plug in the socket.?
What is J connector ? 
Did you mean JST connector that is on the side of 1/4 jack to put at the same place where 1/4 jack is, so that user can solder one that is appropriate to them but not to have both?
Which kind of JST connector are you using?
This one:
1 Like
I don’t like to speak on other’s behalf but @wyleu didn’t respond so… I think he is suggesting that the JST connector is connected through the 1/4" jack contacts so that when you plug a 1/4" jack in, it disconnectes the feed to the JST. (Similar to how some consumer audio devices disconnect the speak when plugging in headhones.) This could allow one or other to operate but I am not convinced of the benefit of such a configuration.
This can be easily done but the problem with that approach is that jack must be soldereed to board even when not in use so that it connects the lines to JST.
1 Like
Ah, a JST-PH type. Thank you 
I have just pushed some changes to testing branch (vangelis) that should enable zynaudio 8x on RPi5. The changes are:
- One-time install of current kernel headers
- Post-install script to install current kernel headers after each kernel update
- Update script to build and install spdif_duplex kernel module
- Update script to install zynaudio8x device tree overlay
- Adds zynaudio8x to webconf soundcards list
The default configuration for zynaudio8x is to enable all 8 inputs and outputs. You may change the settings in Driver Config to change to: 0, 2, 4, 6 or 8 for each, input and output.
This should work. @stojos the reason that installing the headers was not working is because the debian metapackage points at the wrong kernel version. I don’t know if that is a debian, raspberry pi or zynthian issue. I may find the enthusiasm to investigate some time… but for now, we just need to install the correct kernel headers.
1 Like
@riban, thanks a lot!
The hardware:
Wouldn’t it be nice to have ground plane +vcc +i2c +i2s isolation for each stereo pair of inputs or outputs?
In complex setup this would prevent any ground loops or supply hum for the entire setup.
In fact, it would add about 24 Euros to the BOM and a bit more of complexity, but would set this sound card apart from the many that are already on the market.
There has been an Audio Injector with this feature, but they only made the entire card isolated from the Pi, not inputs from outputs and from each other.
Are you considering isolating transformers (large and expensive) or electronic pseudo isolation?