09:12 <tokyovigilante> apritzel: Will try and find some time tomorrow to come to it, I hadn't had much luck yet with corrected timings. Thanks for your comments and testig on the list

14:41 <apritzel> tokyovigilante: if you need any help, let me know. I added .fixed_post_div=2, ORed CCU_FEATURE_FIXED_POSTDIV to .features, then used the correct dividers in the fixed factor clocks, and it worked

14:41 <apritzel> and I tested it on the Tanix TX1, Transpeed 8K618-T, and X96 Mate: worked nicely everywhere

14:55 <apritzel> ... and on the OrangePi Zero3 as well, with a 3.5mm jack wired to the header pins

18:02 <veremootz> 👍 for audio phatz :D

19:03 <tokyovigilante> Nice. I think the SDM dividers are possibly still wrong, the first value should just be the CCU frequency, ie 24 or 22 MHz, so I've set them as per the datasheet but then the multipliers are different again. I think the reason it's working for you is that they don't match and then fall back to fixed timing. Strictly speaking the SDM doesn't have to be enabled for output to work but seeme to be a good idea to have

19:32 <apritzel> are you sure? From my (very shallow) research in the last days this is about "fractional-N PLL / sigma-delta modulation", which seems to be proper rocket science.

19:38 <apritzel> So the integer part of the equation is provided by register 0x078, and the "pattern" takes care of the rest, AFAIK the encoding is non-trivial and not documented?

19:41 <apritzel> 22.5792 MHz = 90316800 / 4 = 24MHz * 22.5792 / 3 / 2

19:43 <apritzel> so N(int)=22, p=3, m0=2, and the pattern does the .5792 part

19:44 <apritzel> tokyovigilante: so what exactly makes you believe it is still wrong? Have you measured the output somehow exactly, and the samplerate is not 100% correct?

20:04 <apritzel> so while I have something playing (at 22050 Hz), I read @0x3001078(PLL_AUDIO_CTRL_REG) as 0xb9021501, and @0x3001178(PLL_AUDIO_PAT0_CTRL_REG) as 0xc001288d, which looks correct to me: SDM is enabled

20:07 <apritzel> and the register bits match the values in the driver

21:43 <apritzel> actually the encoding doesn't seem so mysterious after all, bits [16:0] are just the fractional part (so x/2^17)

21:48 <apritzel> which is actually even described in the H616 manual, at least half way: 3.3.3.9. Spread Spectrum Function