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

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1.1: Type: text/plain, Size: 1969 bytes --]

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.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]