linux-kernel - Re: [alsa-devel] [PATCH v2 1/2] ASoC: ak4118: Add support for AK4118 S/PDIF transceiver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.20.1811141602590.20252@lnxricardw1.se.axis.com>
Date:   Wed, 14 Nov 2018 16:07:21 +0100
From:   Ricard Wanderlof <ricard.wanderlof@...s.com>
To:     Clément Péron <peron.clem@...il.com>
CC:     Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
        Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
        Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>,
        Rob Herring <robh+dt@...nel.org>, <devicetree@...r.kernel.org>,
        <alsa-devel@...a-project.org>,
        Adrien Charruel <adrien.charruel@...ialet.com>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [alsa-devel] [PATCH v2 1/2] ASoC: ak4118: Add support for AK4118
 S/PDIF transceiver

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

> From: Adrien Charruel <adrien.charruel@...ialet.com>
> 
> 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.

/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