Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Alsa headphone detection works but...
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Gentoo on PPC
View previous topic :: View next topic  
Author Message
bzurc51
n00b
n00b


Joined: 03 Feb 2004
Posts: 18

PostPosted: Thu Feb 05, 2004 4:34 am    Post subject: Alsa headphone detection works but... Reply with quote

On my 15" albook (1.25) running 2.6.2_rc1-benh1, the alsa headphone detection works properly and the speakers are muted but when the master volume is adjusted, the speakers unmute. Is this a feature or a bug? Adjusting the PCM level works OK but with pbbuttonsd, the master volume is adjusted so it would be nice if this worked properly. Anyone have this same problem and were able to fix it?
Back to top
View user's profile Send private message
ralph
Advocate
Advocate


Joined: 02 Mar 2003
Posts: 2001
Location: Hamburg

PostPosted: Thu Feb 05, 2004 8:40 am    Post subject: Reply with quote

I'm having the same problem, but only when using the gnome-volume-control. I wasn't able to fix it. The only thing that worked was either not using the gnome-volume-control but gnome-alsamixer, or iirc configuring gvc to control pcm and not the master volume.
_________________
The computer can't tell you the emotional story. It can give you the exact mathematical design, but what's missing is the eyebrows.
- Frank Zappa
Back to top
View user's profile Send private message
gnomeza
Tux's lil' helper
Tux's lil' helper


Joined: 31 Dec 2003
Posts: 97

PostPosted: Thu Feb 05, 2004 12:33 pm    Post subject: RE: Alsa headphone detection works but... Reply with quote

In your pbbuttonsd.conf,
change the line

mixerchannels = "volume, speaker"

to

mixerchannels = "volume"

Now, when you have the headphones plugged in, changing the volume using pbbuttons will not affect the speaker volume.

ciao
gnomeza
Back to top
View user's profile Send private message
ralph
Advocate
Advocate


Joined: 02 Mar 2003
Posts: 2001
Location: Hamburg

PostPosted: Thu Feb 05, 2004 1:01 pm    Post subject: Reply with quote

Thank you, will give it a try. :D
_________________
The computer can't tell you the emotional story. It can give you the exact mathematical design, but what's missing is the eyebrows.
- Frank Zappa
Back to top
View user's profile Send private message
bzurc51
n00b
n00b


Joined: 03 Feb 2004
Posts: 18

PostPosted: Thu Feb 05, 2004 4:27 pm    Post subject: Reply with quote

Gomeza, thanks for the suggestion. Changing the pbbuttonsd.conf to just "volume" did not solve the problem for me. Changing this setting however to "pcm" does work like I described above so this is probably a fine solution for now. It is annoying that every time the master is changed the speakers are unmuted, especially when you are in a place like a library :wink:.
Back to top
View user's profile Send private message
linuxspice
n00b
n00b


Joined: 29 Jan 2004
Posts: 9
Location: Rochester, NY, USA

PostPosted: Sun Feb 08, 2004 7:03 am    Post subject: I think I've figured it out... Reply with quote

This problem has been bugging me a lot, so I decided to dive in and hunt it down. This is what I found.

As gnomeza pointed out earlier in this thread, there *is* a problem with pbbuttonsd's default configuration in that it attempts to control both the "volume" and "speaker" channels. If you remove "speaker" from the "mixerchannels" line and restart pbbuttonsd, pbbuttonsd will indeed no longer attempt to unmute the speaker when you change the volume using the volume keys.

However, it turns out that pbbuttonsd isn't the only daemon that attempts to interact with the mixer channels. The other culprit is the volume control applet that appears at the top right of the GNOME panel by default, the one that looks like a little speaker. This applet is known programmatically as "mixer_applet2", and lives in the /usr/libexec directory. (Just to be clear, this is NOT the same program as the GNOME "Volume Control" application that appears in the "Applications" -> "Multimedia" menu, the one that shows multiple sliders when you open it. That program is the one known programmatically as "gnome-volume-control", and actually plays no direct part in this problem.)

mixer_applet2 doesn't just sit there looking pretty, changing the volume for you only when you click on it and adjust the slider. It also functions as a daemon, constantly monitoring the mixer channels for any changes. Among other reasons, it does this so it can keep the slider position and the number of lines to the right of the speaker icon updated correctly even if a program other than itself (such as gnome-volume-control or pbbuttonsd) changes the volume level or muting status.

From what I can tell by examining the source code, mixer_applet2 also attempts to keep the level of the mixer channel it was configured to control (usually "volume" but sometimes "pcm" or something else) updated whenever it detects any change in the system volume level, whether the change was initiated by mixer_applet2 or another program such as gnome-volume-control or pbbuttonsd. It does this by calling an internal routine, "setMixer()", the GNOME 2.4.0 version of which looks like this (don't worry too much about understanding it if you're not versed in C or programming in general):

Code:
static void
setMixer(gint vol, MixerData *data)
{
   gint tvol;
#ifdef OSS_API
   /* if we couldn't open the mixer */
   if (mixerfd < 0) return;

   tvol = (vol << 8) + vol;
/*g_message("Saving mixer value of %d",tvol);*/
   ioctl(mixerfd, MIXER_WRITE(data->mixerchannel), &tvol);
   
/* SOUND_MIXER_SPEAKER is output level on Mac, but input level on PC. #96639 */
#ifdef __powerpc__
   ioctl(mixerfd, MIXER_WRITE(SOUND_MIXER_SPEAKER), &tvol);
#endif
#endif
#ifdef SUN_API
    audio_info_t ainfo;
   AUDIO_INITINFO (&ainfo);
    ainfo.play.gain = vol;
    ioctl (mixerfd, AUDIO_SETINFO, &ainfo);
#endif
#ifdef IRIX_API
   if (vol < 0)
     tvol = 0;
   else if (vol > VOLUME_MAX)
     tvol = VOLUME_MAX;
   else
     tvol = vol;

   pv_buf[1] = pv_buf[3] = tvol;
   (void) ALsetparams(AL_DEFAULT_DEVICE, pv_buf, MAX_PV_BUF);
#endif
}


Note the two "ioctl" lines with "MIXER_WRITE" in them near the beginning of this function, particularly the second one (the one inside the "__powerpc__" ifdef). Also note the comment referring to bug/issue #96639. Basically, it appears that someone was attempting to fix a volume-related issue on certain Macs, and attempted to solve the problem by making mixer_applet2 set not only the user-configured mixer channel, but also the "speaker" channel as well (SOUND_MIXER_SPEAKER). Whatever this issue is, it is probably for the same reason that pbbuttonsd is initially configured to set both the "volume" and "speaker" channels in the "mixerchannel" line in /etc/pbbuttonsd.conf.

The result of all this: As long as mixer_applet2 is running, whenever *any* program sets the "volume" channel, whether it's gnome-volume-control, pbbuttonsd or anything else, the mixer_applet2 daemon will detect this and set the "speaker" channel as well, which will always cause the speaker to become unmuted. And unlike with pbbuttonsd, there is currently no way to make mixer_applet2 leave the "speaker" channel alone, at least not without patching the source code and recompiling.

The easiest solution for this is to remove the volume control applet from the panel entirely, by right-clicking on it (using a two-button mouse or via your right-mouse-button emulation key) and choosing "Remove From Panel", which will cause it to be shut down. (You can always get it back later if you want, by right-clicking on the panel and choosing "Add to Panel" -> "Multimedia" -> "Volume Control".) You will still be able to use any regular mixer application, including the GNOME "Volume Control" application available via the "Applications" -> "Multimedia" menu, without causing any problems with unmuting. Those of you who are more intrepid could patch the source code to remove the offending line and create your own version of mixer_applet2 to use instead of the original one.

Right now I'm deciding whom to bug about this, and whether or not I have the time and/or skills to create a proper patch for this myself. (I'm a software engineer by trade and am well versed in Windows, Mac OS and Java programmming, but I'm still relatively new to Linux and would want to make sure I'm not messing anything up first.) A really good patch would probably allow you to configure more than one mixer channel to be controlled by mixer_applet2, the same way you can configure more than one mixer channel to be controlled by pbbuttonsd. This way people who needed both the "volume" and "speaker" channels to be controlled could have that capability, and those who wanted only the "volume" channel to be controlled could have that ability as well.

Any comments?
Back to top
View user's profile Send private message
linuxspice
n00b
n00b


Joined: 29 Jan 2004
Posts: 9
Location: Rochester, NY, USA

PostPosted: Sun Feb 08, 2004 7:15 am    Post subject: One other thing... Reply with quote

One thing I forgot to mention: I don't know whether or not this happens in KDE, since I use GNOME and don't have KDE installed on my system (yet anyway). I'd be interested to hear if anyone has observed the same behaviour in KDE, which would indicate that some KDE applet was messing things up in a similar way.
Back to top
View user's profile Send private message
ralph
Advocate
Advocate


Joined: 02 Mar 2003
Posts: 2001
Location: Hamburg

PostPosted: Sun Feb 08, 2004 7:45 am    Post subject: Reply with quote

Thank you linuxspice, great explanation.

I've been using kde and gnome and the problem only appears in gnome.
_________________
The computer can't tell you the emotional story. It can give you the exact mathematical design, but what's missing is the eyebrows.
- Frank Zappa
Back to top
View user's profile Send private message
bzurc51
n00b
n00b


Joined: 03 Feb 2004
Posts: 18

PostPosted: Mon Feb 09, 2004 3:58 am    Post subject: Excellent... Reply with quote

Great job linuxspice, thanks for doing all the footwork on this one. Please file a bug report for this here:

http://bugs.gnome.org/simple-bug-guide.cgi

Seems like you could just use the simple bug report wizard and file it under "Applets". Just paste in your above posting. Is this just a ppc specific issue or would it also affect x86 users? Seems like most of the PC laptops I have used have a hardware toggle when the headphones are plugged in that kill the speakers so maybe this isn't a problem in the PC world? Anyway, I don't have the necessary skills either to work up a clean patch for this so let's just submit this to the development team and see if they'll fix it. Thanks again guys for all the help.
Back to top
View user's profile Send private message
rickb
n00b
n00b


Joined: 04 Dec 2002
Posts: 31
Location: The Hague, Netherlands

PostPosted: Mon Feb 09, 2004 9:28 am    Post subject: Re: One other thing... Reply with quote

linuxspice wrote:
One thing I forgot to mention: I don't know whether or not this happens in KDE, since I use GNOME and don't have KDE installed on my system (yet anyway). I'd be interested to hear if anyone has observed the same behaviour in KDE, which would indicate that some KDE applet was messing things up in a similar way.


Confirmed, same issue on KDE. Been to lazy to dive into it, I just use KMix to shut the speaker up again.
Back to top
View user's profile Send private message
ralph
Advocate
Advocate


Joined: 02 Mar 2003
Posts: 2001
Location: Hamburg

PostPosted: Mon Feb 09, 2004 10:00 am    Post subject: Re: One other thing... Reply with quote

rickb wrote:
linuxspice wrote:
One thing I forgot to mention: I don't know whether or not this happens in KDE, since I use GNOME and don't have KDE installed on my system (yet anyway). I'd be interested to hear if anyone has observed the same behaviour in KDE, which would indicate that some KDE applet was messing things up in a similar way.


Confirmed, same issue on KDE. Been to lazy to dive into it, I just use KMix to shut the speaker up again.


How did you do that? I don't have this issue with kde.
_________________
The computer can't tell you the emotional story. It can give you the exact mathematical design, but what's missing is the eyebrows.
- Frank Zappa
Back to top
View user's profile Send private message
rickb
n00b
n00b


Joined: 04 Dec 2002
Posts: 31
Location: The Hague, Netherlands

PostPosted: Mon Feb 09, 2004 10:48 am    Post subject: Re: One other thing... Reply with quote

ralph wrote:

How did you do that? I don't have this issue with kde.


I'm glad you asked, 'cause it reminds me of the fact that I'm an idiot. I've changed the mixerchannel settings with powerprefs, but I forgot to edit pbbuttonsd.conf, so after a reboot the problem was back....

I should stop using GUI's altogether, they just make me stupid.

So I stand corrected, no such problems with KDE.
Back to top
View user's profile Send private message
linuxspice
n00b
n00b


Joined: 29 Jan 2004
Posts: 9
Location: Rochester, NY, USA

PostPosted: Tue Feb 10, 2004 5:01 am    Post subject: I just filed a bug for this... Reply with quote

I just filed a bug for for this with the GNOME people, #133950. So we'll see what happens from there. If you're interested, you can see it at http://bugs.gnome.org/show_bug.cgi?id=133950 (my explanation there is somewhat more technical and GNOME-specific than the one I gave here, but also has more details about how the speaker and headphone muting and unmuting works on Macs with ALSA).

In response to bzurc51's question, this is indeed a PPC-specific issue. Note the "#ifdef __powerpc__" line that appears before the SOUND_MIXER_SPEAKER line, and the "#endif" line that appears after it; for those of you unfamiliar with C, this construction means that whatever is inside those two lines (the SOUND_MIXER_SPEAKER line in this case) will only be compiled if you're compiling it on a PowerPC machine. It isn't compiled at all for x86 machines. (Interesting fact: apparently the #ifdef/#endif lines didn't originally exist when the SOUND_MIXER_SPEAKER line was first added, and they were added later *precisely because* that line broke things on x86 machines. If you're interested, check out http://bugs.gnome.org/show_bug.cgi?id=96639 and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=164949 for the gory details.)

Let's keep our fingers crossed...
Back to top
View user's profile Send private message
colinleroy
n00b
n00b


Joined: 24 Nov 2003
Posts: 50

PostPosted: Tue Feb 17, 2004 3:48 pm    Post subject: Reply with quote

That was a kernel bug, fixed not long ago in Benh's tree
(see this change: http://ppc.bkbits.net:8080/linuxppc-2.5-benh/diffs/sound/ppc/tumbler.c@1.8.1.8 )
Back to top
View user's profile Send private message
Heimir Freyr
n00b
n00b


Joined: 09 Mar 2003
Posts: 43
Location: Reykjavík, Iceland

PostPosted: Thu Feb 19, 2004 10:42 pm    Post subject: Reply with quote

Maybe my problem is somewhat different from yours, I'm not sure, but I use KDE on a PowerBook Pismo, and whenever I plug in headphones and adjust the sound level (using the buttons on the keyboard, running pbbuttonsd) the built-in speakers get unmuted - which, like someone pointed out, is *terribly annoying* at the library, during class, etc.

I've never as much as touched Gnome, it isn't installed, so I don't think that's the problem in my case.

I'm using oss, not alsa. just the good old dmasound_pmac module.

Any ideas?
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo on PPC All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum