All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Courtier-Dutton <James@superbug.co.uk>
To: Jaroslav Kysela <perex@suse.cz>
Cc: Takashi Iwai <tiwai@suse.de>,
	alsa-devel <alsa-devel@lists.sourceforge.net>
Subject: Re: [PATCH] Implement support for display of dB gain in alsamixer.
Date: Mon, 19 Sep 2005 20:12:50 +0100	[thread overview]
Message-ID: <432F0DB2.7020602@superbug.co.uk> (raw)
In-Reply-To: <Pine.LNX.4.61.0509191722130.8552@dhcp73.suse.cz>

Jaroslav Kysela wrote:
> It's also quite good method, but it avoids having multiple blocks with 
> same keys. For example:
> 
> block1-mixer
> key1
> key2
> /block1-mixer
> block2-pcm
> key1
> key2
> /block2-pcm
> 

This might be nice...looks more and more like XML all the time. ;-)

You might laugh, but getting the kernel to simply build an xml file that 
it then sends to user space is not that difficult. Then one could use 
the bloated xml parsers in user space, and therefore keeping the kernel 
small.

We could even have the control get/set using xml as well.
So, the above in xml:

<block1-mixer>
<key1>some value</key1>
<key2>some other value</key2>
</block1-mixer>
<block2-pcm>
<key1>some value</key1>
<key2>some other value</key2>
</block2-pcm>


Now, we would have to allow for the possible dynamic adding and removal 
of controls, for example, when using qlo10k1 to add a new effect to the 
Audigy 2 DSP.

The mixer api does not have to be high performance, and using XML would 
be endlessly extensible and backward compatible.

Another alternative would be to use the sys filesystem to transfer the 
information. The nesting would be handled using subdirectories, and the 
keys themselves would be individual files in the sys filesystem.
So, representing the above, the sys fs would contain a dir containing:
block1-mixer
block2-pcm

In the block1-mixer dir, one would have the files:
key1
key2
and the contents of the file would be the value of that parameter.

The alsa-lib would just scan the sys file system with subdirectories and 
only use the keys it could understand.

Some keys would be read only, some read/write.
I.e. the db scale key would be read only, but the gain variable would be r/w

I think that the kernel would be happier with us using the sys fs 
instead of xml.

The only other thing we have to consider is the mixer events method.

James


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

      parent reply	other threads:[~2005-09-19 19:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-18 13:31 [PATCH] Implement support for display of dB gain in alsamixer James Courtier-Dutton
2005-09-19 13:36 ` Jaroslav Kysela
2005-09-19 15:20   ` Takashi Iwai
2005-09-19 15:36     ` Jaroslav Kysela
2005-09-19 15:58       ` Takashi Iwai
2005-09-20 12:36         ` Jaroslav Kysela
2005-09-20 14:21           ` Clemens Ladisch
2005-09-21  8:02             ` Jaroslav Kysela
2005-10-06 12:54               ` James Courtier-Dutton
2005-10-06 13:19                 ` Takashi Iwai
2005-11-26 12:02                   ` James Courtier-Dutton
2005-09-19 19:12       ` James Courtier-Dutton [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=432F0DB2.7020602@superbug.co.uk \
    --to=james@superbug.co.uk \
    --cc=alsa-devel@lists.sourceforge.net \
    --cc=perex@suse.cz \
    --cc=tiwai@suse.de \
    /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.