On Fri, Nov 20, 2015 at 10:11:00AM +0100, Moise Gergaud wrote:
Hello,
Please don't top post, reply in line deleting unneeded text. This provides relevant context so people reading your mail can understand what you are talking about.
To be compliant with SPDIF & HDMI-1.4 by using aplay, driver needs to set the channel status sampling freq = runtime rate; because channel status sampling freq is not set by aplay. For HBRA, the application set the channel status sampling freq (that is different than the runtime rate). => by taking into account the 2 above cases, for each pcm session, driver shall be able to detect if the channel status sampling freq has already been set and set it if needed.
And also for robustness purpose: in case the channel status sampling freq is not set by the application, I think the driver shall set it.
None of this addresses my concern, sorry - your change is just trashing all the settings that the application is setting. This is not what we normally do with controls and is going to break correctly functioning applications that play audio with the same parameters repeatedly.
Maybe I can limit my patch by resetting only the channel status sampling freq on close (actual patch reset all the fields of the channel status).
This isn't something you should be inventing policies for in a single driver, the kernel needs to offer consistent interfaces to applications no matter which particular hardware the system is running. If we want to do something here it should be done at ALSA level. It does seem like a reasonable idea to put the sample rate into kernel control, I can't think of a situation where we'd want to advertise the wrong sample rate, but it does need to be in the core not a specific driver.