On Thu, Jan 08, 2015 at 11:44:44AM -0600, Pierre-Louis Bossart wrote:
This matches my definition of an asynchronous SRC. I really don't get what 'synchronous' means here, and it'd seem odd anyway to have 1Hz granularity for the updates?
AIUI it's referring to the intended usage of synchronizing the rates in two domains (which isn't the normal audio terminology).
Adding Tim and Pierre since they might have views if my guess is correct, I could be wrong though.
I'd be good to have a snd_pcm_set_rate() generic framework, but I wonder if it's practical. Hardware with ASRC or tunable PLLs isn't very common except in pro audio, stb, networking and automotive, and usually has specific M/N dividers or rates, I am not sure it can be done generically. Also most servo
ASRC at least is very common in mobile, and in that market people have been driving requirements for on the fly reprogrammability for some use cases (though they've not been delivered universally and this sort of small adjustment in rate wasn't one of the requirements).
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.