On 1/6/15 10:12 PM, Kuninori Morimoto wrote:
Hi Mark
Thank you for your feedback
2nd "dynamic" rate convert which is this patch is used as revision. I don't know detail of use case, but, according to HW team, sound clock has small accidental error. Because of this, if we used 48kHz sound in long term, but, the real sound can be 48001 Hz or 47999 Hz or something like that. So, if we use it without revision in long term, the sound will has small noise. This will be problem for TV or radio (?). Thus, sound player wants to revise it by "dynamic" rate convert. I guess DPCM is good match for "static" rate convert, but not good for "dynamic".
In general it should be fine for anything - the driver for the SoC shouldn't need to understand why the rates are being converted, it should let the system integration worry about picking the rates. That way we can more easily make the frameworks smarter and get benefits over all machines.
Though having said that I'm a little confused as to what exactly this control is intended for - am I right in thinking that what's actually going on here is that something in userspace is measuring the actual measured rate and feeding that information back to the DSP for correction? If that's the case that does seem reasonable but also like we ought to have a general control interface for it.
Yes, you are correct. Actually, I don't know detail of this userspace. (How does it measure actual rate) But, message actual rate -> feedback to SoC is the purpose. (if actual rate was slow -> clock up, actual rate was fast -> clock down)
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?
Is this "general control interface" means "implemented under framework, not drvier" ?
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 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.