All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Giuliano Pochini <pochini@denise.shiny.it>
Cc: Jaroslav Kysela <perex@suse.cz>,
	Adam K Kirchhoff <adamk@voicenet.com>,
	alsa-devel <alsa-devel@lists.sourceforge.net>
Subject: Re: Re: [ALSA - lib 0000154]: Master volume only controls front output (emu10k1)
Date: Fri, 27 May 2005 16:52:37 +0200	[thread overview]
Message-ID: <s5hoeawwwju.wl@alsa2.suse.de> (raw)
In-Reply-To: <Pine.LNX.4.58.0505271615270.15406@denise.shiny.it>

At Fri, 27 May 2005 16:43:18 +0200 (CEST),
Giuliano Pochini wrote:
> 
> On Fri, 27 May 2005, Jaroslav Kysela wrote:
> 
> > > > Hey developers, what's up with the abstract mixer layer? :-)
> > > >
> > >
> > > Anyone?
> >
> > I am working on it, but also doing zillions of other things. The actual
> > status is that the virtual mixer can be created inside the lisp
> > interpreter. I am looking for a clever code design to map the hardware
> > controls with minimal lisp code to abstract ones.... I need something like
> > an object model inside lisp (object == mixer element).
> 
> I was thinking about it, too. I'm not sure the lisp thing is the right
> way. If we want it to be generic enough we have to make a quite big part
> of the API available to the lisp interpreter. It would make the interface
> quite difficult to use and lisp doesn't make things simpler.
> I wonder if, maybe, it is simpler to write a loadable plugin interface and
> write the plugins in C as usual. A plugin is fast (no need to be
> interpreted), it's about as complex as a lisp program (same API) and it
> can be added without recompiling libasound (just like a lisp script) and
> no need to learn lisp :)

Ah, that's what I thought of, too.  In most cases, what we need are:

- create a new user-defined control
- bind several controls to a single one
- convert/correct the different volume ranges

and they can be implemented relatively easily.  We have already the
config-tree parser code, so if the static configuration suffices, the
plugin would work enough.

The only problem of alsa-lib plugin is, again, the OSS emulation in
kernel...


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005

      reply	other threads:[~2005-05-27 14:52 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <da3ba5a8e39a99b562591bfbaba64ac7@bugtrack.alsa-project.org>
2005-05-21  0:26 ` [ALSA - lib 0000154]: Master volume only controls front output (emu10k1) Adam K Kirchhoff
2005-05-27 14:02   ` Adam K Kirchhoff
2005-05-27 14:08     ` Jaroslav Kysela
2005-05-27 14:43       ` Giuliano Pochini
2005-05-27 14:52         ` Takashi Iwai [this message]

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=s5hoeawwwju.wl@alsa2.suse.de \
    --to=tiwai@suse.de \
    --cc=adamk@voicenet.com \
    --cc=alsa-devel@lists.sourceforge.net \
    --cc=perex@suse.cz \
    --cc=pochini@denise.shiny.it \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.