From: Florian Schmidt <mista.tapas@gmx.net>
To: "Lee Revell" <rlrevell@joe-job.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: getting FUSD compiled with current kernels
Date: Sun, 30 Sep 2007 14:29:52 +0200 [thread overview]
Message-ID: <200709301429.53101.mista.tapas@gmx.net> (raw)
In-Reply-To: <75b66ecd0709291826j64c45bcdoc957411f0fb25689@mail.gmail.com>
On Sunday 30 September 2007, Lee Revell wrote:
> On 9/29/07, Florian Schmidt <mista.tapas@gmx.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
next prev parent reply other threads:[~2007-09-30 12:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-29 16:23 Florian Schmidt
2007-09-29 16:35 ` Florian Schmidt
2007-09-29 16:37 ` Florian Schmidt
2007-09-29 17:16 ` Sam Ravnborg
2007-09-30 1:26 ` Lee Revell
2007-09-30 12:29 ` Florian Schmidt [this message]
2007-09-30 15:45 ` Florian Schmidt
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=200709301429.53101.mista.tapas@gmx.net \
--to=mista.tapas@gmx.net \
--cc=linux-kernel@vger.kernel.org \
--cc=rlrevell@joe-job.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®