Hi Mark
I'm wondering if a way of specifying the target rate and a way of reading back the constraints might solve the problem, it seems like a lot of work though.
loops are implemented in firmware or in environments that don't use Linux, not sure how many people would benefit from such additions. At the same time people usually don't use ALSA in such environments because it doesn't do what they want, so it might be worth relooking at adjustable clocks, presentation timestamps, PCR, etc.
Right, that's kind of my thinking here. I'm aware of people doing this stuff in Linux environments outside of ALSA and of people talking about similar hardware capabilities but I don't know what those look like. I don't know if for the time being just defining a control name for the target rate might be enough - doing this fully is probably a big task and I'm not sure anyone is interested right now.
I asked our use case to customer Team. According to them, they are using this rate converter in Digital TV. Digital TV is including its sampling rate, and exchanges it sometimes. Our SoC can exchange sampling rate in SRC, but other SoC needs external circuit (?)
This means my 1st explain (= 48kHz can be 48001 or 47999) seems wrong. They doesn't care about real audio clock.
And, this system (= Digital TV software) is implemented as middleware. So, this is Renesas specific feature, can't be big task (?)
Best regards --- Kuninori Morimoto