Re: [PATCH RFC 5/9] ALSA: core: selection of audio_tstamp type and accuracy reports

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

>> if someone used alsa-lib with the .get_wall_clock(), the new user-space
>> code will provide the same results as today, no change (wall clock if
>> supported, hw_ptr otherwise). So the library compatibility is preserved.
>
> You can't assume that all users always upgrade alsa-lib.
> Users may use still the old alsa-lib with the new kernel.
>
>> I don't mind adding a compatible kernel behavior for HDAudio only, but
>> is this really necessary?
>
> Yes, the kernel is not allowed to give any regression, if we know it
> would.

ok, will add a backwards-compatible mode. no problem.

>> I added a set of INFO defines and the matching is_supported queries in
>> alsa-lib. I just did a pretty dumb copy/paste/edit there, maybe we can
>> refactor the code here with a single routine taking a type parameter.
>> feedback welcome there.
>
> Right.  But another concern is that this method will consume one INFO
> bit at each time the new tstamp type is extended.  This is another
> concern.  Exposing this information in another place would be better,
> IMO, if any better place is found...

I asked about this one in late October... I mentioned that we are 
running out of INFO (half already used) and AZX_CAPS (28 bits used) 
fields, and for INFO it didn't seem like a big deal.
If adding more fields to the info field is viewed as problematic, the 
only options I can think of are:
- reclaim a reserved word in hw_params, e.g. rename to info1 to do 
something like this in alsa-lib:
	return !!(params->info1 & SNDRV_PCM_INFO1_IS_THIS_HARDWARE_BROKEN)
- keep a 32 bit word but add a paging register in the msb to reuse lsbs.
Either way some more code will be required in both driver and library.