All of lore.kernel.org
 help / color / mirror / Atom feed
From: Moise Gergaud <moise.gergaud@st.com>
To: Mark Brown <broonie@kernel.org>
Cc: "tiwai@suse.de" <tiwai@suse.de>,
	"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	Arnaud POULIQUEN <arnaud.pouliquen@st.com>,
	"lgirdwood@gmail.com" <lgirdwood@gmail.com>
Subject: Re: [PATCH 4/4] ASoC: sti: reset iec60958 settings on close
Date: Mon, 23 Nov 2015 09:50:43 +0100	[thread overview]
Message-ID: <5652D363.3090105@st.com> (raw)
In-Reply-To: <20151121124509.GC26072@sirena.org.uk>

On 11/21/2015 01:45 PM, Mark Brown wrote:
> 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.
>

Agree that this should be done at ALSA level.
Taking into consideration this will be done at ALSA level, I still need 
to correct ASOC STI driver: force the iec958 channel status sampling 
rate to the runtime rate without any condition. I'll provide patch V2.

      reply	other threads:[~2015-11-23  8:50 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-19 13:54 [PATCH 0/4] ASoC sti: corrections Moise Gergaud
2015-11-19 13:54 ` [PATCH 1/4] ASoC: sti: remove wrong error message Moise Gergaud
2015-11-19 19:56   ` Applied "ASoC: sti: remove wrong error message" to the asoc tree Mark Brown
2015-11-19 13:54 ` [PATCH 2/4] ASoC: sti: rename ST proprietary DT properties Moise Gergaud
2015-11-19 19:56   ` Applied "ASoC: sti: rename ST proprietary DT properties" to the asoc tree Mark Brown
2015-11-19 13:54 ` [PATCH 3/4] ASoC: sti: set player private data Moise Gergaud
2015-11-19 19:56   ` Applied "ASoC: sti: set player private data" to the asoc tree Mark Brown
2015-11-19 13:54 ` [PATCH 4/4] ASoC: sti: reset iec60958 settings on close Moise Gergaud
2015-11-19 17:50   ` Mark Brown
2015-11-20  9:11     ` Moise Gergaud
2015-11-21 12:45       ` Mark Brown
2015-11-23  8:50         ` Moise Gergaud [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5652D363.3090105@st.com \
    --to=moise.gergaud@st.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=arnaud.pouliquen@st.com \
    --cc=broonie@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.