Re: [PATCH 0/20] ASoC: rsnd: add Synchronous SRC and U/O error salvage support

[Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>]

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.