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]

Date:	Thu, 28 Apr 2016 13:03:22 +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 12:38:22 +0200,
Mark Brown wrote:
> 
> On Wed, Apr 27, 2016 at 10:45:48PM +0200, Peter Rosin wrote:
> > On 2016-04-27 18:15, Mark Brown wrote:
> 
> > > You've not articulated the problem you're trying to fix here, what in
> > > concrete terms is the program trying to accomplish and why should it
> > > succeed?
> 
> > It is opening an OSS fd, and setting some parameters, but changing
> > the speed fails (in this case, since the codec dai has .symmetric_rates).
> > As far as I know this is how you specify a specific speed when using
> > OSS and it is simply not possibly when one of the involved dais is
> > symmetric in any way. Which is silly since there is only one stream,
> > so symmetry should not be an issue.
> 
> Lots of things just don't work with OSS, we stopped caring about it
> years ago.  The configuration mechanism just doesn't play nicely with
> dynamic constraints at all.

True, but looking at the code there, I wonder how only OSS hits.
Does ALSA-native API really work as is...?


> > >>     if ((fd = open("/dev/dsp", O_WRONLY, 0)) == -1) {
> > >>             perror("open");
> > >>             return 1;
> > >>     }
> 
> > > This is using the OSS interfaces which really haven't ever been
> > > especially supported for ASoC.
> 
> > Apparently, how should I know?
> 
> OSS in general had been deprecated for 5-10 years.
> 
> > I haven't looked really closely at the userspace side of this, but the
> > big picture is that we're using a (closed source) library that in its
> > documentation has an example where they open /dev/dsp like this and
> > feeds the fd to the lib. We are simply replicating that in our code.
> > I don't know if the library does anything OSSy with the fd, or if it
> > would be equally happy with an ALSA fd.
> 
> If it's using OSS it's unlikely to work with ALSA, the two ABIs are
> completely different.  You need to talk to your proprietary software
> vendor about updating their software.  There are also some userspace
> utilities that try to do the remapping by wrapping things there but I
> can't remember the names off the top of my head, it's been a long time.

There are a couple of ways.  A simple one is with alsa-oss LD_PRELOAD
wrapper, and another is via CUSE.  Also, PA has own LD_PRELOAD
wrapper.


Takashi