Volume applet: In Dapper, Master does not control Headphones

Bug #36570 reported by Aaron Whitehouse
18
Affects Status Importance Assigned to Milestone
linux-source-2.6.15 (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

I just upgraded to Dapper Flight 5. I have "Volume Applet 2.14.0".

I have inbuilt laptop speakers and a set of headphones. Under Breezy the volume applet controlled both perfectly. The hotkeys also worked for both (do they just talk to the applet anyway?). Now, in Dapper, the applet is set to control "Master" but only changes the volume (or mutes) the laptop speakers and has no effect on headphones.

If I change the preferences and set the applet to control the headphones only, then it works (obviously only for the headphones). The hotkeys do not work for the headphones, even if I change the applet to control 'headphones'.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thanks for your bug. Please describe one issue by bug. The hotkeys acting on master is already known and has an another bug. About the master not changing the headphones, that seems to be the right behaviour to me. Could you try with "alsamixer" if it acts the same way?

Changed in gnome-applets:
assignee: nobody → desktop-bugs
status: Unconfirmed → Needs Info
Revision history for this message
Aaron Whitehouse (aaron-whitehouse) wrote :

Thanks for your help. The reason that I describe both issues in this bug is that I wasn't sure which of them was the bug.

When I have the headphones plugged in, I expect that the hotkeys will control the sound coming out of them. This, as I see it, could be controlled in one of two ways:
- the hotkey could switch from controlling the sound to the speakers to controlling the sound to the headphones ( Bug #21270 ?); or
- the hotkey could always control the Master, but the master could (as the name implies) control or trump all other sound devices. I believe that this is the behaviour in Windows.

I actually prefer the second option as, if you have turned the sound right down, you wouldn't expect it to be very loud when you plug in headphones. If the first option is the way that it is meant to work and Bug #21270 adequately describes this, feel free to dupe this bug :).

Revision history for this message
Sebastien Bacher (seb128) wrote :

To be clear, is your headphone a different device, or just plugged on one of the channel of your soundcard? If that's a different device, the bug is a duplicate of bug #21270. If you are using a channel of the soundcard does alsamixer behaves differently?

Revision history for this message
Aaron Whitehouse (aaron-whitehouse) wrote :

I think that I follow you now. I only have one soundcard. Using the volume applet terminology, I am talking about one 'device' ("Intel 82801DB-ICH4 (Alsa Mixer)").

When I have the volume applet controlling 'track' 'Master', it does not control the headphones. If, in the preferences, I change it so that it is controlling the same 'device' but 'track' 'Headphone', it changes the volume of the headphones. This is the same behaviour as in Alsa Mixer.

Shouldn't the Master control the Headphone track as well?

As I don't have multiple sound cards (it is a standard laptop) , I don't believe that this is a duplicate.

Revision history for this message
Aaron Whitehouse (aaron-whitehouse) wrote :

Sebastien, does this bug still need info or do you have everything that you need from me?

Revision history for this message
Sebastien Bacher (seb128) wrote :

No, we have all the informations. If the alsa mixer acts the same that's an alsa issue, reassigning

Changed in gnome-applets:
assignee: desktop-bugs → pitti
status: Needs Info → Unconfirmed
Revision history for this message
Daniel T Chen (crimsun) wrote :

Aaron, please attach (not inline) output from ``lspci -v && lspci -nv'', thanks.

Changed in alsa-utils:
assignee: pitti → nobody
status: Unconfirmed → In Progress
Changed in linux-source-2.6.15:
status: In Progress → Needs Info
Revision history for this message
Aaron Whitehouse (aaron-whitehouse) wrote : lspci output

I'll attach this to the bug for completeness, even if it was closed as a dupe.

Revision history for this message
Daniel T Chen (crimsun) wrote :
Changed in linux-source-2.6.15:
status: Needs Info → Fix Committed
Changed in linux-source-2.6.15:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.