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.