Adding a alsa mixer interface to ibm-acpi

Adding a alsa mixer interface to ibm-acpi

[Henrique de Moraes Holschuh]

Hello,

I am the current maintainer of the ibm-acpi driver for the Linux kernel.
Those of you that own a ThinkPad notebook probably know what I am talking
about.

A ThinkPad notebook has a hardware mixer for volume control (two functions:
volume and mute).  The user can interact with this volume control using
three buttons (up/down/mute), and it is completely implemented in firmware.

ibm-acpi currently exports those controls through a procfs interface, but I
am trying to get rid of it, and instead of just porting the interface to
sysfs attributes, I tried to write a proof-of-concept alsa mixer -- if it is
a mixer, it should be exported as one, not as some driver-specific sysfs
attributes, IMHO :-)

It worked almost perfectly, and it was easy to write.  Many thanks to
Takashi Iwai for his excellent docs at
http://www.alsa-project.org/~iwai/writing-an-alsa-driver/index.html.

The only issue was in userspace, apparently alsamixer ignores VOLATILE
controls and doesn't poll them for updates.  I wonder how widespread such
misbehaviour is?  I may have to write an in-driver polling thread so that I
can send notifications, if it is too widespread.

Anyway, the driver is *not* a stand-alone module, but rather just a small
part of ibm-acpi.  I suppose I could break it into two modules so that the
alsa mixer has its own module, but either it would *have* to depend on
ibm-acpi, or it would have to duplicate a lot of thinkpad specific stuff.

How do you guys feel about an in-tree module that has alsa stuff in it, but
is not part of the alsa tree?  Would that be a problem?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Adding a alsa mixer interface to ibm-acpi

[Takashi Iwai]

At Sat, 24 Feb 2007 23:20:17 -0200,
Henrique de Moraes Holschuh wrote:
> 
> Hello,
> 
> I am the current maintainer of the ibm-acpi driver for the Linux kernel.
> Those of you that own a ThinkPad notebook probably know what I am talking
> about.
> 
> A ThinkPad notebook has a hardware mixer for volume control (two functions:
> volume and mute).  The user can interact with this volume control using
> three buttons (up/down/mute), and it is completely implemented in firmware.
> 
> ibm-acpi currently exports those controls through a procfs interface, but I
> am trying to get rid of it, and instead of just porting the interface to
> sysfs attributes, I tried to write a proof-of-concept alsa mixer -- if it is
> a mixer, it should be exported as one, not as some driver-specific sysfs
> attributes, IMHO :-)
> 
> It worked almost perfectly, and it was easy to write.  Many thanks to
> Takashi Iwai for his excellent docs at
> http://www.alsa-project.org/~iwai/writing-an-alsa-driver/index.html.
> 
> The only issue was in userspace, apparently alsamixer ignores VOLATILE
> controls and doesn't poll them for updates.  I wonder how widespread such
> misbehaviour is?  I may have to write an in-driver polling thread so that I
> can send notifications, if it is too widespread.

That's exactly the role of VOLATILE flag.  It's for controls with
frequently changing elements (e.g. VU-meters) and thus not suitable
for poll/select by a mixer app.  I think the case of volume buttons is
OK to use normal controls without VOLATILE flag.

> Anyway, the driver is *not* a stand-alone module, but rather just a small
> part of ibm-acpi.  I suppose I could break it into two modules so that the
> alsa mixer has its own module, but either it would *have* to depend on
> ibm-acpi, or it would have to duplicate a lot of thinkpad specific stuff.
> 
> How do you guys feel about an in-tree module that has alsa stuff in it, but
> is not part of the alsa tree?  Would that be a problem?

I'm basically for including it in ALSA driver (suppose intel8x0?) as
long as it's directly related with the sound.  If you have a working
patch, I'm willing to review and discuss more.

Anyway, the reply will be delayed since I'll be in vacation from now
for a week or so.


Thanks,

Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [Alsa-devel] Adding a alsa mixer interface to ibm-acpi

[Henrique de Moraes Holschuh]

On Mon, 26 Feb 2007, Takashi Iwai wrote:
> > The only issue was in userspace, apparently alsamixer ignores VOLATILE
> > controls and doesn't poll them for updates.  I wonder how widespread such
> > misbehaviour is?  I may have to write an in-driver polling thread so that I
> > can send notifications, if it is too widespread.
> 
> That's exactly the role of VOLATILE flag.  It's for controls with
> frequently changing elements (e.g. VU-meters) and thus not suitable
> for poll/select by a mixer app.  I think the case of volume buttons is
> OK to use normal controls without VOLATILE flag.

Well, since these controls change without notice (user might press a volme
button in the keyboard, and the firmware will change the volume by itself),
I will have to poll them myself and send notifications.

> > Anyway, the driver is *not* a stand-alone module, but rather just a small
> > part of ibm-acpi.  I suppose I could break it into two modules so that the
> > alsa mixer has its own module, but either it would *have* to depend on
> > ibm-acpi, or it would have to duplicate a lot of thinkpad specific stuff.
> > 
> > How do you guys feel about an in-tree module that has alsa stuff in it, but
> > is not part of the alsa tree?  Would that be a problem?
> 
> I'm basically for including it in ALSA driver (suppose intel8x0?) as
> long as it's directly related with the sound.  If you have a working
> patch, I'm willing to review and discuss more.

It is not directly related to the sound card *at* *all*.  It is done by the
thinkpad embedded controller firmware.

So, it really is a "different card", and doesn't belong in any of the many
sound card drivers that work on the various thinkpad models.  Since it is
only one extra mixer control, if the API allows it, we *could* piggy back it
on the mixer for the real sound card, but that looks like extra complexity
and layering violations for no good reason to me.

If I have it as a separate snd-thinkpadmixer module or somesuch, that module
will need some code from the main ibm-acpi module to work.  It needs the
ACPI bus, and also thinpad-specific knowledge...  sounds messy to have it on
a different tree, thus the question about how complicated would it be to
have it in the ibm-acpi driver instead of submitting it for the alsa tree.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [ibm-acpi-devel] Adding a alsa mixer interface to ibm-acpi

[Takashi Iwai]

At Mon, 26 Feb 2007 13:28:19 -0300,
Henrique de Moraes Holschuh wrote:
> 
> On Mon, 26 Feb 2007, Takashi Iwai wrote:
> > > The only issue was in userspace, apparently alsamixer ignores VOLATILE
> > > controls and doesn't poll them for updates.  I wonder how widespread such
> > > misbehaviour is?  I may have to write an in-driver polling thread so that I
> > > can send notifications, if it is too widespread.
> > 
> > That's exactly the role of VOLATILE flag.  It's for controls with
> > frequently changing elements (e.g. VU-meters) and thus not suitable
> > for poll/select by a mixer app.  I think the case of volume buttons is
> > OK to use normal controls without VOLATILE flag.
> 
> Well, since these controls change without notice (user might press a volme
> button in the keyboard, and the firmware will change the volume by itself),
> I will have to poll them myself and send notifications.

Hm, yes, if there is no irq or such, the polling is the only way...

> > > Anyway, the driver is *not* a stand-alone module, but rather just a small
> > > part of ibm-acpi.  I suppose I could break it into two modules so that the
> > > alsa mixer has its own module, but either it would *have* to depend on
> > > ibm-acpi, or it would have to duplicate a lot of thinkpad specific stuff.
> > > 
> > > How do you guys feel about an in-tree module that has alsa stuff in it, but
> > > is not part of the alsa tree?  Would that be a problem?
> > 
> > I'm basically for including it in ALSA driver (suppose intel8x0?) as
> > long as it's directly related with the sound.  If you have a working
> > patch, I'm willing to review and discuss more.
> 
> It is not directly related to the sound card *at* *all*.  It is done by the
> thinkpad embedded controller firmware.
> 
> So, it really is a "different card", and doesn't belong in any of the many
> sound card drivers that work on the various thinkpad models.  Since it is
> only one extra mixer control, if the API allows it, we *could* piggy back it
> on the mixer for the real sound card, but that looks like extra complexity
> and layering violations for no good reason to me.

Hm, I think the problem is how to export the sound card object to the
outside.  Currently the created instance is closed in the ALSA tree,
and there is no direct way to get the pointer from another driver.
That's why I thought of including the code in the ALSA tree.  But, we
can add an export to enable the hook in each card driver code.

> If I have it as a separate snd-thinkpadmixer module or somesuch, that module
> will need some code from the main ibm-acpi module to work.  It needs the
> ACPI bus, and also thinpad-specific knowledge...  sounds messy to have it on
> a different tree, thus the question about how complicated would it be to
> have it in the ibm-acpi driver instead of submitting it for the alsa tree.

I think it's no big problem to leave it in another tree since the
control API is fairly stable right now.


Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [ibm-acpi-devel] Adding a alsa mixer interface to ibm-acpi

[Henrique de Moraes Holschuh]

On Mon, 26 Feb 2007, Takashi Iwai wrote:
> > It is not directly related to the sound card *at* *all*.  It is done by the
> > thinkpad embedded controller firmware.
> > 
> > So, it really is a "different card", and doesn't belong in any of the many
> > sound card drivers that work on the various thinkpad models.  Since it is
> > only one extra mixer control, if the API allows it, we *could* piggy back it
> > on the mixer for the real sound card, but that looks like extra complexity
> > and layering violations for no good reason to me.
> 
> Hm, I think the problem is how to export the sound card object to the
> outside.  Currently the created instance is closed in the ALSA tree,
> and there is no direct way to get the pointer from another driver.
> That's why I thought of including the code in the ALSA tree.  But, we
> can add an export to enable the hook in each card driver code.

Well, adding a new card that only has a mixer and no PCM or other sound
properties seems to work just fine, and it is *much* simpler than piggying
back a new *system global* control on top of AC97, many HDA chips, etc.  It
is also that much easier to deal with.

Can I keep it as a separate card?

> > If I have it as a separate snd-thinkpadmixer module or somesuch, that module
> > will need some code from the main ibm-acpi module to work.  It needs the
> > ACPI bus, and also thinpad-specific knowledge...  sounds messy to have it on
> > a different tree, thus the question about how complicated would it be to
> > have it in the ibm-acpi driver instead of submitting it for the alsa tree.
> 
> I think it's no big problem to leave it in another tree since the
> control API is fairly stable right now.

Then I should have a proper version of the thinkpad volume control as an
alsa mixer ready soon, registering it as a separate card.  I can change that
to a piggy-back mixer control later, if you'd rather I did that.

The ibm-acpi module does not follow the module parameter specs of alsa sound
modules, is that a problem?  I don't expect alsa configurator tools to ever
deal with the ibm-acpi mixer, but...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [Alsa-devel] Adding a alsa mixer interface to ibm-acpi

[Theodore Tso]

On Mon, Feb 26, 2007 at 02:41:45PM -0300, Henrique de Moraes Holschuh wrote:
> Well, adding a new card that only has a mixer and no PCM or other sound
> properties seems to work just fine, and it is *much* simpler than piggying
> back a new *system global* control on top of AC97, many HDA chips, etc.  It
> is also that much easier to deal with.
> 
> Can I keep it as a separate card?

I guess I'm wondering what value is added by exporting it as a
separate ALSA card.  Ideally it should be integrated into the
thinkpad's real sound card.  Otherwise sound applications will have no
idea that this separate mixer-only sound card has anything to do with
the main speaker output (as compared to the Skype headset I have
plugged into the USB port).  

I suppose it does mean you can use alsamixer to manipulate the sound,
but from the user's point of view, if it's not visible when they right
clock on the mixer applet (because it's not associated with the
laptop's primary sound card), is it really that useful?

Regards,

					- Ted

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [ibm-acpi-devel] Adding a alsa mixer interface to ibm-acpi

[Henrique de Moraes Holschuh]

On Mon, 26 Feb 2007, Theodore Tso wrote:
> thinkpad's real sound card.  Otherwise sound applications will have no
> idea that this separate mixer-only sound card has anything to do with
> the main speaker output (as compared to the Skype headset I have
> plugged into the USB port). 

True.  That's the downside.   The upside is that we don't need to create a
new API to allow the piggy-back.  After all, the real soundcard module could
get loaded *after* ibm-acpi... or it could be removed before ibm-acpi.  The
"piggy-back mixer control" would need an API with full hotplug semanthics.

> I suppose it does mean you can use alsamixer to manipulate the sound,
> but from the user's point of view, if it's not visible when they right
> clock on the mixer applet (because it's not associated with the
> laptop's primary sound card), is it really that useful?

If they got a mixer applet worth something, it will list two cards, or allow
them to have two instances, one for each card.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [ibm-acpi-devel] Adding a alsa mixer interface to ibm-acpi

[Takashi Iwai]

At Mon, 26 Feb 2007 23:14:02 -0300,
Henrique de Moraes Holschuh wrote:
> 
> On Mon, 26 Feb 2007, Theodore Tso wrote:
> > thinkpad's real sound card.  Otherwise sound applications will have no
> > idea that this separate mixer-only sound card has anything to do with
> > the main speaker output (as compared to the Skype headset I have
> > plugged into the USB port). 
> 
> True.  That's the downside.   The upside is that we don't need to create a
> new API to allow the piggy-back.  After all, the real soundcard module could
> get loaded *after* ibm-acpi... or it could be removed before ibm-acpi.  The
> "piggy-back mixer control" would need an API with full hotplug semanthics.

Well, it's a question whether this should be an add-on module or a
built-in to the sound driver.  From the usability viewpoint, the
latter is much easier.  Then we have no module loading order problem
and need no API extension.  Of course, the drawback is that the
unnecessary growth of the code / binary size for non-thinkpad users.

> > I suppose it does mean you can use alsamixer to manipulate the sound,
> > but from the user's point of view, if it's not visible when they right
> > clock on the mixer applet (because it's not associated with the
> > laptop's primary sound card), is it really that useful?
> 
> If they got a mixer applet worth something, it will list two cards, or allow
> them to have two instances, one for each card.

I guess it's rather confusing.  Both controls the very same device for
the very same role in the end, so it'd be better to be merged in some
level, IMO.


Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [Alsa-devel] Adding a alsa mixer interface to ibm-acpi

[Henrique de Moraes Holschuh]

On Wed, 07 Mar 2007, Takashi Iwai wrote:
> Well, it's a question whether this should be an add-on module or a
> built-in to the sound driver.  From the usability viewpoint, the
> latter is much easier.  Then we have no module loading order problem
> and need no API extension.  Of course, the drawback is that the
> unnecessary growth of the code / binary size for non-thinkpad users.

Which is quite a serious drawback.  I am not at all opposed to writing a
mixer piggy-back, but IMHO if we are going to do it that way, it would be
best to create an API that allows an alsa module to extend the functionality
of another module, *and* provide the proper callbacks to have it work in
full hotplug mode (i.e. it will do the right thing no matter in which way
the modules are loaded, and also if the device is hotplugged or
hotunplugged).

> > > I suppose it does mean you can use alsamixer to manipulate the sound,
> > > but from the user's point of view, if it's not visible when they right
> > > clock on the mixer applet (because it's not associated with the
> > > laptop's primary sound card), is it really that useful?
> > 
> > If they got a mixer applet worth something, it will list two cards, or allow
> > them to have two instances, one for each card.
> 
> I guess it's rather confusing.  Both controls the very same device for
> the very same role in the end, so it'd be better to be merged in some
> level, IMO.

Very well.  Do you want me to start a "requirements" document for the API,
so that we can start walking down that road?

On the ibm-acpi side, I can just merge in the mixer as a separate card for
now, with the proper notices that it is not a stable interface and that it
will go away in the future.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [Alsa-devel] Adding a alsa mixer interface to ibm-acpi

[Shem Multinymous]

On 3/7/07, Takashi Iwai <tiwai-l3A5Bk7waGM@public.gmane.org> wrote:
> > If they got a mixer applet worth something, it will list two cards, or allow
> > them to have two instances, one for each card.
>
> I guess it's rather confusing.  Both controls the very same device for
> the very same role in the end, so it'd be better to be merged in some
> level, IMO.

The ibm-acpi mixer also affects the BIOS-generated sounds (e.g.,
low-battery warnings) and PC speaker. So it useful even when the sound
card is unused or unsupported.

  Shem

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [ibm-acpi-devel] Adding a alsa mixer interface to ibm-acpi

[Tobin Davis]

[-- Attachment #1.1: Type: text/plain, Size: 413 bytes --]

On Wed, 2007-03-07 at 18:12 -0500, Shem Multinymous wrote:

> 
> The ibm-acpi mixer also affects the BIOS-generated sounds (e.g.,
> low-battery warnings) and PC speaker. So it useful even when the sound
> card is unused or unsupported.
> 

Don't those sounds go through the beep generator?  Most codecs use a
beep generator for system sounds, that routes through the codec.

-- 
Tobin Davis <tdavis@dsl-only.net>

[-- Attachment #1.2: Type: text/html, Size: 973 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [ibm-acpi-devel] Adding a alsa mixer interface to ibm-acpi

[Shem Multinymous]

On 3/7/07, Tobin Davis <tdavis@dsl-only.net> wrote:
>  On Wed, 2007-03-07 at 18:12 -0500, Shem Multinymous wrote:
>
>      The ibm-acpi mixer also affects the BIOS-generated sounds (e.g.,
>      low-battery warnings) and PC speaker. So it useful even when the sound
>      card is unused or unsupported.
>
>   Don't those sounds go through the beep generator?  Most codecs use a beep
>  generator for system sounds, that routes through the codec.

In my ThinkPad the system sound volume is affected by ibm-acpi but not
by any ALSA mixer settings. As far as I can tell, it behaves as if
AC'97 (including all ALSA mixers) and system sound are generated
independently, added together, and then scaled by the ibm_acpi mixer.

  Shem

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [ibm-acpi-devel] Adding a alsa mixer interface to ibm-acpi

[Henrique de Moraes Holschuh]

On Wed, 07 Mar 2007, Shem Multinymous wrote:
> On 3/7/07, Takashi Iwai <tiwai@suse.de> wrote:
> > > If they got a mixer applet worth something, it will list two cards, or allow
> > > them to have two instances, one for each card.
> >
> > I guess it's rather confusing.  Both controls the very same device for
> > the very same role in the end, so it'd be better to be merged in some
> > level, IMO.
> 
> The ibm-acpi mixer also affects the BIOS-generated sounds (e.g.,
> low-battery warnings) and PC speaker. So it useful even when the sound
> card is unused or unsupported.

True.  Here's the (probable) audio routing on a ThinkPad:

[embedded sound card/codec] -> [thinkpad hardware mixer] -> output
[thinkpad firmware beep generator]   ----^

The thinkpad firmware can generate a bunch of beeps that appear to not be
really related to the std. PC buzzer :-)  and these beeps are used to signal
firmware events.  I don't think they are routed through the AC97 or HDA
codec.

Note that it is possible that the normal PC buzzer IS routed through the
codec.

One of the things I don't know is exactly what is generating the firmware
beeps on modern thinkpads: BIOS, or EC.  The volume control is done by the
EC on a modern thinkpad, though.

So I'd have to provide a stand-alone "placeholder" card to hook the mixer to
if no real sound-card driver is loaded?  urk.  It is doable, of course,
but... ick.  The question is now, what should I do when doing a mixer
piggy-back?  De-register the mixer-only audio card, or keep it around (and
this give the user two cards)?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [ibm-acpi-devel] Adding a alsa mixer interface to ibm-acpi

[Tobin Davis]

On Wed, 2007-03-07 at 20:42 -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 07 Mar 2007, Shem Multinymous wrote:
> > On 3/7/07, Takashi Iwai <tiwai@suse.de> wrote:
> > > > If they got a mixer applet worth something, it will list two cards, or allow
> > > > them to have two instances, one for each card.
> > >
> > > I guess it's rather confusing.  Both controls the very same device for
> > > the very same role in the end, so it'd be better to be merged in some
> > > level, IMO.
> > 
> > The ibm-acpi mixer also affects the BIOS-generated sounds (e.g.,
> > low-battery warnings) and PC speaker. So it useful even when the sound
> > card is unused or unsupported.
> 
> True.  Here's the (probable) audio routing on a ThinkPad:
> 
> [embedded sound card/codec] -> [thinkpad hardware mixer] -> output
> [thinkpad firmware beep generator]   ----^
> 
> The thinkpad firmware can generate a bunch of beeps that appear to not be
> really related to the std. PC buzzer :-)  and these beeps are used to signal
> firmware events.  I don't think they are routed through the AC97 or HDA
> codec.
> 
> Note that it is possible that the normal PC buzzer IS routed through the
> codec.
> 
> One of the things I don't know is exactly what is generating the firmware
> beeps on modern thinkpads: BIOS, or EC.  The volume control is done by the
> EC on a modern thinkpad, though.
> 
> So I'd have to provide a stand-alone "placeholder" card to hook the mixer to
> if no real sound-card driver is loaded?  urk.  It is doable, of course,
> but... ick.  The question is now, what should I do when doing a mixer
> piggy-back?  De-register the mixer-only audio card, or keep it around (and
> this give the user two cards)?
Another question comes to mind.  Why would the volume need to be
controlled if there is no sound driver to generate sound?  I'm trying
to understand the usage model here for that aspect.

As to the firmware controlling the sound mixer when drivers are loaded,
what about creating an unsolicited event situation that is specifically
masked to each control?  That would be an easy addition to the hda codec
drivers (not sure about AC'97).


-- 
Tobin Davis <tdavis@dsl-only.net>


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [Alsa-devel] Adding a alsa mixer interface to ibm-acpi

[Henrique de Moraes Holschuh]

On Wed, 07 Mar 2007, Tobin Davis wrote:
> Another question comes to mind.  Why would the volume need to be
> controlled if there is no sound driver to generate sound?  I'm trying
> to understand the usage model here for that aspect.

Because the firmware will happly beep away, and you may want to control the
volume of those beeps.  And it also controls the volume of the PC buzzer
(the BIOS makes sure whatever sound hardware is in the machine lets that one
through by default).

> As to the firmware controlling the sound mixer when drivers are loaded,
> what about creating an unsolicited event situation that is specifically
> masked to each control?  That would be an easy addition to the hda codec
> drivers (not sure about AC'97).

I can deal with that just fine, but I'd still need to somehow tell all
codecs (not just hda, ac97 -- let's make this generic) that I am providing
such an interface, and that I want an extra (monoaural in the case of
thinkpads, others might want stereo) global (volume/tone/whatever) mixer
control, that can produce such events.

And the interface needs to be bidirectional, so that I can update the
control.

And I need to be able to pinpoint which card should add this interface, so
that I can track down the correct embedded card (using model-specific
knowledge) and, e.g., exclude USB and CardBus sound cards...  that means I
need to somehow access for every card in the system what bus and busID it is
hanging off.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [ibm-acpi-devel] Adding a alsa mixer interface to ibm-acpi

[Takashi Iwai]

At Wed, 7 Mar 2007 21:38:06 -0300,
Henrique de Moraes Holschuh wrote:
> 
> On Wed, 07 Mar 2007, Tobin Davis wrote:
> > Another question comes to mind.  Why would the volume need to be
> > controlled if there is no sound driver to generate sound?  I'm trying
> > to understand the usage model here for that aspect.
> 
> Because the firmware will happly beep away, and you may want to control the
> volume of those beeps.  And it also controls the volume of the PC buzzer
> (the BIOS makes sure whatever sound hardware is in the machine lets that one
> through by default).

OTOH, from the usability POV, it's really annoying to have two
individual "devices" for the very same output.  That's why I'm in
favor of either built-in-sound-driver or add-on style.

And, if you'll ALSA API for controlling volumes, it assumes that any
sound system is running.   So, it appears logical to me that the
beep-control driver also belongs to a sound driver.

Anyway, if you'd like a stand-alone implementation, we can introduce a
Kconfig, too.  But, note that one merit to use the add-on style
(referring to the exported symbol of snd-intel8x0 driver) is that this
dependency will resolve the module loading order, too.


Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [Alsa-devel] Adding a alsa mixer interface to ibm-acpi

[Henrique de Moraes Holschuh]

On Fri, 09 Mar 2007, Takashi Iwai wrote:
> > On Wed, 07 Mar 2007, Tobin Davis wrote:
> > > Another question comes to mind.  Why would the volume need to be
> > > controlled if there is no sound driver to generate sound?  I'm trying
> > > to understand the usage model here for that aspect.
> > 
> > Because the firmware will happly beep away, and you may want to control the
> > volume of those beeps.  And it also controls the volume of the PC buzzer
> > (the BIOS makes sure whatever sound hardware is in the machine lets that one
> > through by default).
> 
> OTOH, from the usability POV, it's really annoying to have two
> individual "devices" for the very same output.  That's why I'm in
> favor of either built-in-sound-driver or add-on style.

Well, I have five choices:

1. No Linux support to change the thinkpad mixer at all unless the soundcard
drivers are loaded;

2. ThinkPad mixer support always available as a separate, mixer-only card;

3. ThinkPad mixer support available as a separate mixer-only card AND in the
real soundcard driver;

4. ThinkPad mixer support available as a separate mixer-only card while the
real soundcard driver is not loaded, and *only* in the real soundcard driver
after it is loaded;

5. ThinkPad mixer support available in the real soundcard driver, and as a
bunch of non-generic attributes on sysfs.

> And, if you'll ALSA API for controlling volumes, it assumes that any
> sound system is running.   So, it appears logical to me that the

It seems to work just fine with the soundsystem running with a card that
only has a single monoaural volume control, and nothing else.

> beep-control driver also belongs to a sound driver.

Does ALSA have an interface that is sane for a hardware/firmware synthesizer
with a fixed set of tones?  The MIDI sequencer doesn't count, it is unusable
for scripts.  Otherwise, I will keep the non-generic ibm-acpi interface (a
sysfs attribute where you write the ID of the pattern you want it to beep).

> Anyway, if you'd like a stand-alone implementation, we can introduce a
> Kconfig, too.  But, note that one merit to use the add-on style
> (referring to the exported symbol of snd-intel8x0 driver) is that this
> dependency will resolve the module loading order, too.

We still need to handle hotplug anyway, as modules can be removed and
readded.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [ibm-acpi-devel] Adding a alsa mixer interface to ibm-acpi

[Takashi Iwai]

At Sat, 10 Mar 2007 00:50:55 -0300,
Henrique de Moraes Holschuh wrote:
> 
> On Fri, 09 Mar 2007, Takashi Iwai wrote:
> > > On Wed, 07 Mar 2007, Tobin Davis wrote:
> > > > Another question comes to mind.  Why would the volume need to be
> > > > controlled if there is no sound driver to generate sound?  I'm trying
> > > > to understand the usage model here for that aspect.
> > > 
> > > Because the firmware will happly beep away, and you may want to control the
> > > volume of those beeps.  And it also controls the volume of the PC buzzer
> > > (the BIOS makes sure whatever sound hardware is in the machine lets that one
> > > through by default).
> > 
> > OTOH, from the usability POV, it's really annoying to have two
> > individual "devices" for the very same output.  That's why I'm in
> > favor of either built-in-sound-driver or add-on style.
> 
> Well, I have five choices:
> 
> 1. No Linux support to change the thinkpad mixer at all unless the soundcard
> drivers are loaded;
> 
> 2. ThinkPad mixer support always available as a separate, mixer-only card;
> 
> 3. ThinkPad mixer support available as a separate mixer-only card AND in the
> real soundcard driver;
> 
> 4. ThinkPad mixer support available as a separate mixer-only card while the
> real soundcard driver is not loaded, and *only* in the real soundcard driver
> after it is loaded;
> 
> 5. ThinkPad mixer support available in the real soundcard driver, and as a
> bunch of non-generic attributes on sysfs.
> 
> > And, if you'll ALSA API for controlling volumes, it assumes that any
> > sound system is running.   So, it appears logical to me that the
> 
> It seems to work just fine with the soundsystem running with a card that
> only has a single monoaural volume control, and nothing else.
> 
> > beep-control driver also belongs to a sound driver.
> 
> Does ALSA have an interface that is sane for a hardware/firmware synthesizer
> with a fixed set of tones?  The MIDI sequencer doesn't count, it is unusable
> for scripts.  Otherwise, I will keep the non-generic ibm-acpi interface (a
> sysfs attribute where you write the ID of the pattern you want it to beep).
> 
> > Anyway, if you'd like a stand-alone implementation, we can introduce a
> > Kconfig, too.  But, note that one merit to use the add-on style
> > (referring to the exported symbol of snd-intel8x0 driver) is that this
> > dependency will resolve the module loading order, too.
> 
> We still need to handle hotplug anyway, as modules can be removed and
> readded.

The problem I state here is only the usability.  The implementation is
no matter at all.  When you look at KDE/GNOME, you'll find that the
mixer applets really suck if you have multiple devices.  It's
especially confusing if the outputs from two different devices are
identical...


Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [ibm-acpi-devel] Adding a alsa mixer interface to ibm-acpi

[Henrique de Moraes Holschuh]

On Mon, 12 Mar 2007, Takashi Iwai wrote:
> The problem I state here is only the usability.  The implementation is
> no matter at all.  When you look at KDE/GNOME, you'll find that the
> mixer applets really suck if you have multiple devices.  It's

Then, it is time for them to fix their broken-as-designed applets.  ALSA has
supported multiple devices since way too long for mixer applets to have any
valid excuse to not handle multiple cards sanely.

> especially confusing if the outputs from two different devices are
> identical...

So no two devices with the same control set.  That makes sense, and cuts
down the choices a bit.

Anyway, I thought about the issue for quite a while, and the above point
about the KDE/GNONE applets and no duplication of controls just gave me the
last pieces of the puzzle:

1. It *is* separate hardware, it has nothing to do with whatever might be
the embedded soundcard and codecs, except that it sits between them and the
speakers and line-out jacks.

2. It controls more than just the embedded soundcard, it also controls the
PC squeaker (independently of the embedded soundcard being able to control
that or not), and also the firmware ACPI/APM/alarm beep generator.

Therefore, it should go in a different card.  That works just fine, it
requires no new API in ALSA, it follows the kernel standard for these things
(if it is a separate device, export it as a separate device), and it makes a
lot more sense from the system's point of view.

A non-broken ALSA mixer applet will just let you add itself twice to the
applet bar: once to control the thinkpad mixer, and the other to control the
embedded soundcard.  Or it will allow you to pick your favourite set of
controls out of those available from every card in the system.

The above makes too much sense.  I must have forgotten something, it can't
be that simple.  Would someone be so kind and point out why the above will
just not work well in real life?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [ibm-acpi-devel] Adding a alsa mixer interface to ibm-acpi

[Alex Deucher]

On 3/12/07, Henrique de Moraes Holschuh <hmh@hmh.eng.br> wrote:
> On Mon, 12 Mar 2007, Takashi Iwai wrote:
> > The problem I state here is only the usability.  The implementation is
> > no matter at all.  When you look at KDE/GNOME, you'll find that the
> > mixer applets really suck if you have multiple devices.  It's
>
> Then, it is time for them to fix their broken-as-designed applets.  ALSA has
> supported multiple devices since way too long for mixer applets to have any
> valid excuse to not handle multiple cards sanely.
>
> > especially confusing if the outputs from two different devices are
> > identical...
>
> So no two devices with the same control set.  That makes sense, and cuts
> down the choices a bit.
>
> Anyway, I thought about the issue for quite a while, and the above point
> about the KDE/GNONE applets and no duplication of controls just gave me the
> last pieces of the puzzle:
>
> 1. It *is* separate hardware, it has nothing to do with whatever might be
> the embedded soundcard and codecs, except that it sits between them and the
> speakers and line-out jacks.
>
> 2. It controls more than just the embedded soundcard, it also controls the
> PC squeaker (independently of the embedded soundcard being able to control
> that or not), and also the firmware ACPI/APM/alarm beep generator.
>
> Therefore, it should go in a different card.  That works just fine, it
> requires no new API in ALSA, it follows the kernel standard for these things
> (if it is a separate device, export it as a separate device), and it makes a
> lot more sense from the system's point of view.
>
> A non-broken ALSA mixer applet will just let you add itself twice to the
> applet bar: once to control the thinkpad mixer, and the other to control the
> embedded soundcard.  Or it will allow you to pick your favourite set of
> controls out of those available from every card in the system.
>
> The above makes too much sense.  I must have forgotten something, it can't
> be that simple.  Would someone be so kind and point out why the above will
> just not work well in real life?
>

I agree.  I think it makes sense to have it as a separate device.

Alex

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV