Hi Mark
Thank you for your feedback
OK, that's more what I thought this was originally. It sounds like a fairly standard ASRC deployment where the goal is to match the rate the system wants to play audio at to the rate that the target hardware needs. That's not too different to the telephony cases where the system is in one clock domain (possibly at a very different sample rate) and the baseband another and definitely the sort of thing that DPCM is intended to support.
This really would be better done with DPCM with the userspace control being provided by the driver for the tuner or the machine driver and passed through to set the rate of the back end. Do you think that's achieveable (even if it's just a mostly dummy DAI here)? That way if this is used in a system with a CODEC with a real driver on the end of the link things should just work.
Can I confirm about this ? This means, we can..
- add "sampling rate convert" support on DPCM (= our "static" sampling rate convert can use it) - add "sampling rate convert interface" support for userland on DPCM (= our "dynamic" sampling rate convert can use it)
I think this is achieveable.
My concern about this is card driver with DT. I and Mark talked about it in LinuxCon before, and adding DPCM support with DT on simple-card is very difficult (= simple-card is not "simple" today...) So, I will create new sound card driver which includes DPCM DT support for this purpose. Then, should I create "renesas-sound-card" under sound/soc/sh ? or can I create "multi-card" (I don't know this is good naming...) under sound/soc/generic ? If we can select later choice, it will have very limited feature, but simple DPCM support
Best regards --- Kuninori Morimoto