linux-kernel - Re: getting FUSD compiled with current kernels

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:	Sun, 30 Sep 2007 14:29:52 +0200
From:	Florian Schmidt <mista.tapas@....net>
To:	"Lee Revell" <rlrevell@...-job.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: getting FUSD compiled with current kernels

On Sunday 30 September 2007, Lee Revell wrote:
> On 9/29/07, Florian Schmidt <mista.tapas@....net> wrote:
> > My goal is to hack up oss2jack [3] to use ALSA pcm devices.. And a later
> > goal is to create a virtual ALSA soundcard [which would multiplex access
> > to a real non hw-mixing capable soundcard] to finally end the dmix
> > software mixing woes linux users have to endure for the last years :)
>
> What problems with ALSA's userspace mixing are you trying to solve?

I think that for example the aoss approach to providing software mixing to OSS 
apps is fundamentally flawed. The LD_PRELOAD_LIBRARY mechanism does not work 
for all applications. The OSS emultion in ALSA that does work for pretty much 
all OSS apps is the kernel level OSS emulation [which directly provides the 
OSS conform device files] sitting directly on an ALSA device driver module. 
Having a virtual ALSA soundcard which would route back to userspace one could 
make the OSS emu use this device instead providing to-userspace routing of 
all OSS apps..

The same argument, though in a weaker form holds for badly coded ALSA apps 
which open soundcards "directly" via "hw:0" pcm device names. It would be 
cool, if these could be made to play nice trivially. Here again, a virtual 
ALSA device which routes back to userspace would be great..

Simply make the virtual device card 0 in the system..

Dmix wouldn't be obsoleted by this at all. I'm not sure on the details (still 
learning), but the virtual ALSA device routing the signal back to user space 
could then in turn use dmix on a real alsa device to provide the sw mixing 
(it would indeed be a very thin userspace driver as it basically directly 
uses an ALSA pcm as "slave")..

This is not thought of as a replacement for ALSA userspace libasound2.. Not at 
all. It's just a cool thing to have (tm) in many situations, solving these 
cases which drive some ALSA users (me included) nuts :)

Regards,
Flo

-- 
Palimm Palimm!
http://tapas.affenbande.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/