[alsa-devel] [PATCH 4/4] ASoC: sti: reset iec60958 settings on close

[Mark Brown]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20151121/551d062e/attachment.sig>