mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®