linux-kernel - Re: [PATCH] ASoC: pcm: allow changing the playback/capture rates for symmetric links

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: <s5hy47yszzm.wl-tiwai@suse.de>
Date:	Thu, 28 Apr 2016 14:02:21 +0200
From:	Takashi Iwai <tiwai@...e.de>
To:	Mark Brown <broonie@...nel.org>
Cc:	Peter Rosin <peda@...ntia.se>, alsa-devel@...a-project.org,
	Liam Girdwood <lgirdwood@...il.com>,
	Jaroslav Kysela <perex@...ex.cz>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ASoC: pcm: allow changing the playback/capture rates for symmetric links

On Thu, 28 Apr 2016 13:41:50 +0200,
Mark Brown wrote:
> 
> On Thu, Apr 28, 2016 at 01:26:49PM +0200, Takashi Iwai wrote:
> > Mark Brown wrote:
> 
> > > We've had the code for years without anyone reporting issues so...  the
> > > idiomatic ALSA thing is to set everything in one call which helps a lot.
> 
> > Yes, most of such problems come from the inconsistent hw constraints,
> > and one-shot configuration helps indeed.  But, in this case, it
> > appears more like an overlooked case to me.
> 
> If there's a useful report with the ALSA API then let's look into that -
> if people can only see this with the OSS API and can't articulate an
> actual ALSA API level problem then I'm struggling to care.  Drivers that
> do parameter validation tend to fail with OSS anyway as it tries to set
> partially configured hw_params with invalid values in them and it's not
> clear to me that this isn't the same thing happening again.

Yeah, that's why I asked whether this really doesn't happen in ALSA
native API.


> > BTW, this reminds me of another question: don't we have a dummy ASoC
> > driver like snd-dummy?  It would be convenient for a casual API
> > testing.
> 
> No, someone would need to write a series of dummy drivers that exercised
> the various API features (almost all of which are kernel internal) and
> then instantiated them but nobody stepped up and did that yet.

Well, we don't support all API features there.  Developer can modify
the existing code and test it quickly if needed at any time once when
the base code is present.  So, yeah, we need a volunteer!


Takashi