The pwm generator needs additional control input through I2C. This input controls the general items like how to generate the pwm, what filter settings, volume, ...
Yes, I didn't tdraw the control plane, only the "music plane".
As we consider pwm as analog the wiring should be short, very short!
Your analog path will be longer than what I sketched as the analog path also includes the speaker wire.
Optical transfer may be possible but will be very delicate - Implementing this is ambigous and hardware usually used for TOSLINK may not be sufficient (but maybe a interesting approach to try!).
Audio Input to the pwm generator usually is I2S which can be generated from any type of source with a small electronic (DAC (e.g. TI), spdif/toslink --> i2s converter (e.g. Wolfssohn), ...).
Eventually the controller and the SB (which I like a lot) may go into the same device.
Many "high-end" people do not like TOSLINK (and SPIF) due to timing - we used I2S for this which worked out excellent - with many more components.
There are now much higher performing opto systems that are feasible cost wise than when Toslink was conceived.
The timing and jitter probably is not a big issue if you use the same clock for digitizing and for converting back into the "high power digital" world. In this case they should cancel out. But if they are not the same (or if you use digital music sources) it matters a lot.
(the sawtooth picture only holds if you use an analog signal and digitize it - which gives you double noise and distortion sources).
If we think for the pwm over opto we cannot have any protocol - this is the time domain of the audio signal (or the true "analog pwm") and needs to be transferred without losses. Has anyone experience with the TI PWM concept? I guess each of the pwm signals (3.5µsec @ 280 kHz) needs to be digitized with 16(24) bit?? So this ends up with a timing of 54psec(213fsec) which is far out of reach for a diy project (and for the analog path this sounds hard to meet as well) - can anybody here in the forum tell me where my mistake is - I'm sure something is wrong with these numbers
Why digitize it? Just send it as light on-light off corresponding to when the flank shall be high or low. PWM is just switching between low and high and its the time *when* it switches that carry the relevant info - right?
And so we are back to the original setup with the pwm generator close to the power stage. I still separate these into two building blocks, as the requirements for the pcb, wiring and signal quality are totally different for these two. We can still have them side by side which then gives the flexibility I proposed in the early posts and which avoids the issues discussed above.
And I suppose in one and the same box and even on the same circuit board I assume?
Regarding the TOSLINK and the jitter issues - you are right nowadays optoelectronics is far better than it used to be at the time TOSLINK was defined. But it's not only the jitter in the physical layer which the "high end" people dislike. The protocol has some inherent jitter due to the metadata coded in the spdif.
I think this is not really inherent jitter but a problem for the decoder and clock extraction circuit not to be influenced of some repetitive patterns which per definition is not intended for carrying info about time. An implementation design flaw and not a specification flaw - this has been mostly cured nowadays when the industry has accepted and understood the relevance of time accuracy at the point for D/A conversion. But in practice when sp/dif where used as a time reference it is (was?) a problem.
This was the reason we used I2S because here jitter is non relevant due to the input gates at the receiver. One can improve that even further if the MCLK is utilized (which is not part of the I2S spec) and further if this is based on a good clock... .. all this is additional margin to improve further.
Isn't i2s is a short haul protocol intended for "on circuit board use" - sp/dif for external consumer interface so not direct comparable. Its often advised against using I2C for longer runs or over connectors between boxes.