linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ricard Wanderlof <ricard.wanderlof@axis.com>
To: "Clément Péron" <peron.clem@gmail.com>
Cc: Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
	Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>, Rob Herring <robh+dt@kernel.org>,
	<devicetree@vger.kernel.org>, <alsa-devel@alsa-project.org>,
	Adrien Charruel <adrien.charruel@devialet.com>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [alsa-devel] [PATCH v2 1/2] ASoC: ak4118: Add support for AK4118 S/PDIF transceiver
Date: Thu, 15 Nov 2018 17:47:28 +0100	[thread overview]
Message-ID: <alpine.DEB.2.20.1811151742510.20252@lnxricardw1.se.axis.com> (raw)
In-Reply-To: <CAJiuCcd_LAhODGGu=EBj4WBvx2PufcVbw=tO1+Mm+1Hj0k6BRw@mail.gmail.com>


On Wed, 14 Nov 2018, Clément Péron wrote:

> > > The AK4118A is a digital audio transceiver supporting 8 input channels
> > > at 192kHz and with 24bits resolution.
> > > It converts the S/PDIF signal to I2S format and is configurable over I2C.
> > >
> > > This driver introduce a minimal support of the AK4118, like selecting the
> > > input channel, reading input frequency and detecting some errors.
> >
> > I'm curious, from what it seems, there is no checking that the input
> > sample rate actually matches the configured sample rate? It's perfectly
> > understandable for a driver which has 'minimal support', but it's
> > something a user must be aware of; for instance if someone does
> >
> > arecord -r 48000 output.wav
> >
> > when the input data actually has a rate of 44100 Hz then the file will be
> > written with a header specifying 44100 Hz but the data will actually be
> > 48000 Hz.
> >
> > It's not an objection on my part, just an observation. I don't know how
> > ALSA could enforce this in any way; ideally (barring automatic sample rate
> > conversion) one would want an error message that the sample rate specified
> > when opening the stream does not match the sample rate of the S/PDIF input
> > data.
> 
> I'm quite new with linux audio driver but adding in ak4118_hw_params a
> check like if params_rate(params) == ak4118_rate should do the job no

It will if the SPDIF stream is already running when the driver is started 
up, but if for some reason the sample rate changes or the SPDIF source is 
not transmitting anything when the stream is started it won't work to do 
it hw_params. A changing sample rate might be an unusual usecase, but one
could imagine having an SPDIF source which is silent (e.g. not even 
plugged in) when the stream is set up.

Like I said, it might not be a problem in many applications. And I'm not 
really sure how to solve it. Perhaps someone else knows. ALSA likes to be 
in control of parameters such as the sample rate, but it can't with an 
external device controlling the sample rate of the SPDIF receiver.

/Ricard
-- 
Ricard Wolf Wanderlof                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

      reply	other threads:[~2018-11-15 16:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-14 12:16 Clément Péron
2018-11-14 12:16 ` [PATCH v2 2/2] ASoC: dt-bindings: add bindings for AK4118 transceiver Clément Péron
2018-11-17 15:51   ` Rob Herring
2018-11-19 10:55     ` Clément Péron
2018-11-14 15:07 ` [alsa-devel] [PATCH v2 1/2] ASoC: ak4118: Add support for AK4118 S/PDIF transceiver Ricard Wanderlof
2018-11-14 15:24   ` Clément Péron
2018-11-15 16:47     ` Ricard Wanderlof [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=alpine.DEB.2.20.1811151742510.20252@lnxricardw1.se.axis.com \
    --to=ricard.wanderlof@axis.com \
    --cc=adrien.charruel@devialet.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=kuninori.morimoto.gx@renesas.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=peron.clem@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=tiwai@suse.com \
    --subject='Re: [alsa-devel] [PATCH v2 1/2] ASoC: ak4118: Add support for AK4118 S/PDIF transceiver' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).