Regression - Volume Control using gnome panel applet and keyboard shortcut alternates mute / % volume during sliding

Bug #126333 reported by QB89Dragon
180
This bug affects 2 people
Affects Status Importance Assigned to Milestone
GNOME Applets
Fix Released
Medium
GStreamer
Invalid
High
gnome-applets (Ubuntu)
Fix Released
Low
Ubuntu Desktop Bugs
gnome-settings-daemon (Ubuntu)
Fix Released
Low
Ubuntu Desktop Bugs

Bug Description

On my sony vaio VGN-FZ11M, running metacity, and having been upgraded successfully from feisty, volume change on the keyboard shortcut used to produce a small box on screen showing the volume level. On gutsy, I get a larger grey square at the bottom somewhat offcenter from the screen with just a grey square, no controls.

In Ubuntu 7.04, Volume Control was no issue; the QuickKeys (Volume Up/Down/Mute) on the side worked very well. Also the keyboard shortcuts (Fn/PageUp and Fn/PageDown) were equally smooth.
When I clicked on the Panel's Sound Icon, moving the volume slider was also smooth and accurate.

In Ubuntu 7.10, the Quick Keys and shortcut keys are erratic, meaning that a single tap of a key can one time mute the sound or move it to maximum. When I click on the Panel's Sound icon and move the slider up and/or down, the display on the mouse pointer alternates from a number (percentage) to "Muted" to a number to "Muted", etc (but it doesn't affect the real sound itself)

Tags: bitesize
Revision history for this message
Brian Murray (brian-murray) wrote :

Thanks for taking the time to report this bug and helping to make Ubuntu better. This bug did not have a package associated with it, which is important for ensuring that it gets looked at by the proper developers. You can learn more about finding the right package at https://wiki.ubuntu.com/Bugs/FindRightPackage . I have classified this bug as a bug in gnome-applets-data.

Additionally you may consider adding a screenshot of the issue to your bug report as that may be more helpful than a text description of the problem.

Revision history for this message
Pedro Villavicencio (pedro) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. May you take an screenshot an attach it to the report?, thanks in advance.

Changed in gnome-applets:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: New → Incomplete
Revision history for this message
Marco Rodrigues (gothicx) wrote :

I can confirm it on Tribe-4.. when using scroll wheel of mouse it doesn't show any percentage of volume level.

Revision history for this message
Marco Rodrigues (gothicx) wrote :
Changed in gnome-applets:
status: Unknown → New
Changed in gnome-applets:
status: Incomplete → Triaged
Revision history for this message
Sergio Zanchetta (primes2h) wrote :

I put this as a duplicate of Bug #153570.
I think this bug is more related to compiz than gnome-applets.

In Bug #153570 there is a video attached also.

Revision history for this message
Sergio Zanchetta (primes2h) wrote :

I revert duplicates because this one is older and already checked.

Changed in compiz:
status: New → Confirmed
Revision history for this message
Niosop (niosop) wrote : Re: [GUTSY] Regression - Volume Control Bar doesn't slide when using keyboard shortcut

I don't know if it helps, but the problem was present on Kubuntu 7.10 as well, not using compiz or beryl (straight X, no XGL or AIGLX). I don't believe that Kubuntu uses gnome-applets. It could be a separate problem that happens to look a lot like this one, or there could be a lower level root cause that affects both. I opened a bug on that, but it was merged with this.

Revision history for this message
RobPower (robpwr) wrote :

I can confirm it on Kubuntu 7.10 (upgraded from 7.04).
If I use Fn Key down it shows the popup volume bar going down till 0%, but doesn't affect the volume.
If I use Fn Key Up, it shows the popup volume bar, but that bar can't go upper than 11% volume, and doesn't affect the real volume.
If I use Fn Mute Key it shows the right popup ("mute activated"/"mute deactivated") but it doesn't affect the volume.

I have Compix installed but actually not running.
Please help, it's an annoying bug..
If any log i s needed just ask.
Thank you and good work.

Revision history for this message
Travis Watkins (amaranth) wrote :

This doesn't seem to be related to compiz but I'm not sure what to assign it to. Removing package instead of marking bug as invalid because bug mail from invalid bugs makes me sad.

Changed in compiz:
status: Confirmed → New
Revision history for this message
Niosop (niosop) wrote :

On one of my Kubuntu 7.10 installs, reinstalling a variety of packages fixed the problem. I just started reinstalling in alphabetical order, and did about 20 packages. It may only affect 7.04-7.10 upgrades and not new installs. I have a second install exhibiting the same behavior, I'll start reinstalling packages on it and see which one fixes it.

Revision history for this message
Sergio Zanchetta (primes2h) wrote : Re: [Bug 126333] Re: [GUTSY] Regression - Volume Control Bar doesn't slide when using keyboard shortcut

For me it happened on a fresh install with Ubuntu.

2007/11/11, Niosop <email address hidden>:
> On one of my Kubuntu 7.10 installs, reinstalling a variety of packages
> fixed the problem. I just started reinstalling in alphabetical order,
> and did about 20 packages. It may only affect 7.04-7.10 upgrades and
> not new installs. I have a second install exhibiting the same behavior,
> I'll start reinstalling packages on it and see which one fixes it.
>
> --
> [GUTSY] Regression - Volume Control Bar doesn't slide when using keyboard shortcut
> https://bugs.launchpad.net/bugs/126333
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
Tim Richardson (tim-richardson) wrote : Re: [GUTSY] Regression - Volume Control Bar doesn't slide when using keyboard shortcut

For me, on Debian unstable, the volume hotkeys do not change the volume as seen in the gnome volume preference panel. The volume hotkeys change linein, if linein is enabled in the volume preference. If linein is not enabled, then the volume hotkeys do nothing. The volume hotkeys worked until recently.

Revision history for this message
Tim Richardson (tim-richardson) wrote :

my problem with Debian was unrelated.

Revision history for this message
Sergio Zanchetta (primes2h) wrote :

This is a bad regression from Feisty.
Is it worth to be considered for Hardy?

description: updated
description: updated
Revision history for this message
Pedro Villavicencio (pedro) wrote : Re: [GUTSY] Regression - Volume Control using gnome panel applet and keyboard shortcut alternates mute / % volume during sliding

Yes, if it's fixed durind the cycle it will be available in Hardy, patches are welcome :-).

Revision history for this message
Robin Sheat (eythian) wrote :

Just further confirmation, I see this with the mousewheel on two quite different machines, one a 64-bit desktop that has two soundcards, both do it, one a 32-bit laptop that does it with the builtin one, and also with an external one that's sometimes attached. The latter also does it when using the media keys. The former doesn't have media keys.

Revision history for this message
Robin Sheat (eythian) wrote :

Just to add another...I also see it on a 3rd computer with yet another soundcard (dunno what it is, but it's old. I can find the model if it's useful).

Revision history for this message
zig59 (zig-59) wrote :

Just to add twopenneth, mute/volume level shows up on sound applet when adjusting using the mousewheel but sound carries on as normal. Volume level appears to be accurate but sound continues when showing muted. Explicitly muting (keyboard button or applet right-click) does mute the sound.

I have had this on a Feisty -> Gutsy upgrade and a clean install of Gutsy (32bit desktop). Hardware is Abit AN8-V motherboard CK804 AC'97 onboard sound chipset using Alsa.

Not sure what info to include but will do if asked for. Have included screenshot showing muted sound (take my word for it the music was playing) but the alsa mixer window (centre bottom) is not showing any mute (the applet is set to control the master volume). The mute box on the applet right-click context menu was showing the sound as muted though. Unfortunately I couldn't screendump while the context menu was up.

Revision history for this message
Pascal De Vuyst (pascal-devuyst) wrote :

No need to have a generic Ubuntu task if we have a task on a specific package in Ubuntu, closing Ubuntu task.

Revision history for this message
Sergio Zanchetta (primes2h) wrote :

It's fixed in Hardy Alpha 6 (live cd).

Revision history for this message
Mike (bild85) wrote :

It is NOT fixed in Hardy Alpha 6. At least not when installed to HD. It's MUCH better than it was; in fact it doesn't seem to jump around at all now. But the volume applet still displays muted when it is not.

Attached are three cropped screenshots. Because balloon tips are not included in a screencapture, you'll have to take my word that the balloon tip was displaying "Master: 12%", "Master: Muted", "Master: 19%". The volume level was not muted and sounded normal.

Ubuntu version info is below. I'm glad to provide any more data as requested. Please keep in mind that we're not all developers here, so asking me which code segment I'm referring to or demanding a backtrace might result in a glazed-over look. :)

$ uname -a
Linux hostname 2.6.24-12-generic #1 SMP Wed Mar 12 23:01:54 UTC 2008 i686 GNU/Linux

$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=8.04
DISTRIB_CODENAME=hardy
DISTRIB_DESCRIPTION="Ubuntu hardy (development branch)"

Revision history for this message
KIAaze (zohn-joidberg) wrote :

I can confirm this bug too. Had it for a while now. The importance may be low, but it gives off a bad image of Ubuntu since it's very visible...

$ lspci -v | grep -i audio
00:06.0 Multimedia audio controller: ALi Corporation M5451 PCI AC-Link Controller Audio Device (rev 02)
$ uname -a
Linux mike-laptop 2.6.24-12-generic #1 SMP Wed Mar 12 23:01:54 UTC 2008 i686 GNU/Linux
$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=8.04
DISTRIB_CODENAME=hardy
DISTRIB_DESCRIPTION="Ubuntu hardy (development branch)"

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

there is no need to copy all the lsb informations to say that you get the issue on hardy, those comments just make the bug harder to read. Could anybody provide easy steps to trigger the bug? An comment about what image it gives are not really constructive there, the bug is there only on specific configurations and only a small annoyance

Revision history for this message
Andrea Corbellini (andrea.corbellini) wrote :
Revision history for this message
Mike (bild85) wrote :

Great video, Andrea! The mute icon and balloon tip also shows up if you simply point to the volume applet and spin the mouse scroll wheel.

Steps to reproduce:
1.) Install Ubuntu
2.) Point mouse to Volume Applet
3.) Spin scroll wheel and watch the applet change into a mute icon momentarily

I reproduced the symptoms using the following versions, on multiple platforms:
7.10, 8.04 Alpha 6, 8.04 Beta

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

Thanks for the video, the issue is clear on it and I can confirm it's not happening on my installations, must depend of the soundcard used, that will require debugging by somebody having hardware to trigger the issue and try changes

Revision history for this message
Andrea Corbellini (andrea.corbellini) wrote :

That's strange because I've an integrated Intel soundcard. However, I've attached my /dev/sndstat, tell me if it is enough.

Revision history for this message
Andrea Corbellini (andrea.corbellini) wrote :

I'd like to tell you also that this happens only with the applet, not with the Volume Control window.

Revision history for this message
Robin Sheat (eythian) wrote :

I've just upgraded to Hardy beta, and no longer see this issue, fwiw.

Revision history for this message
Pichu0102 (pichu0102-deactivatedaccount) wrote :

Recent updates seem to have fixed this issue, as it no longer appears after today's batch of Hardy beta updates, while it appeared before today's hardy updates.

Unsure of what has changed, but it no longer has this behavior.

Revision history for this message
Pichu0102 (pichu0102-deactivatedaccount) wrote :

Nevermind; bug has reappeared.

Appears to manifest itself after starting Amarok, and gets a bit worse the more you stop and start playing, although it might be an over time after boot thing. However, launching khelpcenter also seemed to make the bug appear again briefly right after a reboot and before starting Amarok.

Revision history for this message
Mark Grandi (markgrandi) wrote :

I am also getting this with hardy beta 1 (all updates applied as of march 26 2008)

use the scroll wheel to increase the volume and the applet goes down in volume and the applet shows mute, and other strange behavior

Revision history for this message
KIAaze (zohn-joidberg) wrote :

The volume applet seems to work correctly for me now. (Bug#136837: https://bugs.launchpad.net/ubuntu/+source/gnome-applets/+bug/136837).

However, I still have problems using the special keys on the side of the laptop to change volume.
In the Keyboard shortcuts dialog, they are:
-XF86AudioLowerVolume
-XF86AudioRaiseVolume

When I use the raise volume key, it always goes to the max.
When I use the lower volume key, the volume bar (which gets displayed in the middle of the screen) goes to zero completely, but the volume is only lowered a bit in reality.

Changed in gnome-applets:
status: New → Invalid
Revision history for this message
Robin Sheat (eythian) wrote :

Volume applet still doesn't work correctly for me with Hardy on my laptop when using the mouse wheel on the volume applet. I've attached a video showing what's going on. Note that I'm always turning the mouse wheel up, one click at a time, and when the applet shows mute, there is no sound (it is actually muted). The volume level jumping down is due to the applet, not me turning the wheel backwards.

Revision history for this message
Karl Dane (karl-rince) wrote :

I have a relatively unique setup in that I currently have three sound 'devices' running on my machine:

- an onboard VIA soundcard. Relevant entry from lspci: 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60)

- An external USB Terratec 'aureon' sound device. Relevant entry from lsusb: '00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60)'

- An external USB Creative 'xmod' sound device. Relevant entry from lsusb: 'Bus 003 Device 006: ID 041e:30d0 Creative Technology, Ltd'

I get all sorts of weird and wonderful behavious with this arrangement, and they're different depending upon which soundcard I'm using.

First of all, the gnome-volume-control segfaults the moment I try to run it. (You'll probably want an apport or similar trace from this. I'll sort that out shortly. But I need to learn how to use these tools first, which I'll do when I'm not being paid by somebody else for my time...)

The VIA works reliably in all circumstances. In particular, the volume up and down keys on my keyboard work as expected if System -> Preferences -> Sounds is set to use that device by default.

When I'm using the terratec box as default, keyboard shortcuts have the desired effect upon the volume, but the pop-up volume control display is erratic; the volume bar leaps all over the place with each change in volume. The volume may have just been set to 20%, but it will show 100%, then with another change the display will leap to 0%.

When I'm using the xmod box as default (my preferred arrangement) then it's even stranger; the displayed volume leaps up and down erratically in the same way as the terratec device (terratic? ;) ) above, but the actual volume setting also does the same. I can hear this, but I can also quantify this visually if I have the gnome alsa mixer open at the same time; the volume bar leaps up and down. But even worse, the balance bar, as well as the actual balance setting, leaps about the place too.

I should add that changing settings using the gnome alsa mixer 'gnome-alsamixer 0.9.7~cvs.20060916.ds.1-1' works reliably and as expected on all of my sound devices.

I agree that this is a low priority issue; certainly not a showstopper, but I'd love to get this fixed, so I'm very happy to perform any tests anybody requests of me to help out.

Thanks,

Karl Dane

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

the issue described there seems to be bug #136837 which has been fixed in hardy, if you still have an issue in hardy better to open a new bug now

Changed in gnome-applets:
status: Triaged → Fix Released
Revision history for this message
Robin Sheat (eythian) wrote :

Not really fixed. See the video I posted above, that's on hardy.

Revision history for this message
Sergio Zanchetta (primes2h) wrote : Re: [Bug 126333] Re: [GUTSY] Regression - Volume Control using gnome panel applet and keyboard shortcut alternates mute / % volume during sliding

Yes Sebastien
It's fixed for me in Hardy.

2008/4/30 Sebastien Bacher <email address hidden>:

> the issue described there seems to be bug #136837 which has been fixed
> in hardy, if you still have an issue in hardy better to open a new bug
> now
>
> ** Changed in: gnome-applets (Ubuntu)
> Status: Triaged => Fix Released
>
> --
> [GUTSY] Regression - Volume Control using gnome panel applet and keyboard
> shortcut alternates mute / % volume during sliding
> https://bugs.launchpad.net/bugs/126333
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
Sergio Zanchetta (primes2h) wrote : Re: [GUTSY] Regression - Volume Control using gnome panel applet and keyboard shortcut alternates mute / % volume during sliding

Sorry, I was wrong.
I was fixed only the volume applet issue.
Changing volume with mouse wheel in volume applet on the right upper corner works nice now.

But there is still the problem with keyboard shortcut keys.
I can't see orange volume bar sliding when I'm changing volume with shortcut keys.
See screenshot.

Changed in gnome-applets:
status: Fix Released → Confirmed
Revision history for this message
Sebastien Bacher (seb128) wrote :

don't reopen the gnome-applets bug if the applet works correctly

Changed in gnome-applets:
status: Confirmed → Fix Released
Revision history for this message
Sergio Zanchetta (primes2h) wrote :

I thought it was still a gnome-applets problem.
So what's correct package to add here?

I can't guess which package is related to volume bar gui through keyboard shortcuts.

Revision history for this message
Richard Laager (rlaager) wrote :

I'm seeing this with keyboard shortcuts on Gutsy and Hardy as well. I worked around it for now by moving the keybindings from the "special" volume up, down, mute to be metacity run_command_* bindings. The commands I used were as follows:

Volume Down:
amixer -c 0 set PCM 2dB

Volume Up:
amixer -c 0 set PCM 2dB+ unmute

Volume Mute:
amixer -c 0 set PCM mute

While I don't get the on-screen display, this works fine. This seems to suggest that this is a GNOME volume control issue and not one in the driver. For reference, I have an HP Pavilion dv8000 with an HDA Intel card.

Sebastien, I can test whatever you'd like.

Revision history for this message
Richard Laager (rlaager) wrote :

This clearly affects some package in Ubuntu. Unless and until someone sets the right package (or moves this to another bug), this task can track it.

Revision history for this message
Sergio Zanchetta (primes2h) wrote :

I put as a gnome-settings-daemon bug, it looks like a good candidate.

Feel free to change it if you find out the correct package.

Revision history for this message
unggnu (unggnu) wrote :

I can confirm this with Hardy but it doesn't mute the sound it all it only doesn't show the volume bar.

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

could you describe easy steps to trigger the issue on a stock ubuntu installation and maybe provide screenshots showing the bug?

Changed in gnome-settings-daemon:
importance: Undecided → Low
status: Confirmed → Incomplete
Revision history for this message
unggnu (unggnu) wrote :

I have two audio devices but if connected only the Audigy2 is used. The volume keys change the Master controller. Afaik this happens with only one connected sound card too but I am going to recheck it soon.

Audio device: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller (rev 03)
Multimedia audio controller: Creative Labs SB0400 Audigy2 Value

1.increase or decrease (but always in one direction) volume
2.after around 4 changes the bar should be gone
3.if you change volume after that the bar is shown again

Revision history for this message
unggnu (unggnu) wrote :
Revision history for this message
Sergio Zanchetta (primes2h) wrote :

In fact the bar is showed sometimes for a very little time (just a little bit), appear and disappear randomly (for example try to press increasing button repeatedly starting from mute)

00:06.0 Multimedia audio controller: ALi Corporation M5451 PCI AC-Link Controller Audio Device (rev 02)

There is also a very strange thing.
Just after booting, it work perfectly.
After doing something, like using applications etc., it starts to go bad. I don't know yet if it is related to applications themselves or some system load for example.

Revision history for this message
James Westby (james-w) wrote :

Hi,

This is probably the same cause as bug 136837.

Thanks,

James

Revision history for this message
unggnu (unggnu) wrote :

Just for the records it happens with one sound card too. I guess it is a general gnome sound applet problem. It even happens with Compiz.

Revision history for this message
Mark Grandi (markgrandi) wrote :

the bug says fix released, but im using hardy with all updates and this is still a major problem. I cant even change the volume it keeps spazzing between 20% and 64%, and then the left channel cuts out half the time, ugg.

Revision history for this message
James Westby (james-w) wrote : Re: [Bug 126333] Re: Regression - Volume Control using gnome panel applet and keyboard shortcut alternates mute / % volume during sliding

On Tue, 2008-05-13 at 04:53 +0000, Polygon wrote:
> the bug says fix released, but im using hardy with all updates and this
> is still a major problem. I cant even change the volume it keeps
> spazzing between 20% and 64%, and then the left channel cuts out half
> the time, ugg.
>

You mean changing it with the panel applet?

If that is so could you please file a new bug, as this problem does
indeed seem to be fixed for most people, so it may be specific to
your chipset, or something else.

Thanks,

James

Revision history for this message
Mark Grandi (markgrandi) wrote :
Changed in gnome-applets:
status: Unknown → Confirmed
Revision history for this message
Richard Laager (rlaager) wrote :

> could you describe easy steps to trigger the issue on a stock ubuntu installation and maybe provide screenshots showing the bug?

I installed Hardy. I have two user accounts that I've had for a while:
 A) My user account does NOT use compiz. It is set to have the volume control control "PCM". It exihibits this bug: Changing the volume "works" but jumps back down to zero randomly.
 B) Another user account, which has probably been logged into twice, apparently uses compiz (or whatever to get the bigger volume control on-screen display). The volume control preference there has *nothing* selected. Thus, the volume control goes up and down fine when you press the keys, but it doesn't actually control anything.

I added a brand new user account and it behaves like B. If I change it (in the Sounds preference panel) to control PCM, I get broken behavior. I didn't see it randomly drop to zero, but it would move in differently sized steps and randomly not move. (In other words, I could hit UP and it wouldn't do anything, but the next UP would make it go up.)

Revision history for this message
8-bit Blaster (neon-lime) wrote :

I have this exact same problem -- the volume bars move erratically when I try to move any of them up or down. I've actually had this problem for over a year.

1) Double click the volume icon in the top panel.
2) Try to move any of the vertical sliders.
3) Watch the sliders bounce from absolute-max to absolute-min.
4) Watch the stereo "chain" break and each channel's slider goes in a different direction.

Revision history for this message
xtknight (xt-knight) wrote :

This isn't fixed in Hardy. It is still there in the applet and the volume control.

gnome-alsamixer doesn't have a problem, but the gstreamer-based volume control applet and gnome-volume-control still do. I have tried this on two computers with Hardy and it still happens with Intrepid too with two different sounds cards (a C-Media-based Turtle Beach Montego DDL and an Audigy2). I've tried all the patches and spent 6 hours debugging the problem on my own. It seems that the audio driver is giving me random values for volume indicating a problem at a lower level but I am certainly not sure this is the case. alsamixer and gnome-alsamixer work fine. So while the bug may not be in gnome-applets there is certainly a bug somewhere for some of us.

Changed in gnome-applets:
status: Fix Released → New
Revision history for this message
xtknight (xt-knight) wrote :

I'm sorry for changing this. I am going to open a new bug elsewhere.

Changed in gnome-applets:
status: New → Fix Released
Revision history for this message
Bogdan (bogpetre) wrote :

xtknight,

Could you give us a few more details regarding what you tried during these "6 hours" aside from patching? I'd like to continue to work on this issue, but I've reached the limits of my knowledge. If I could get a hint as to alternative directions I could take in debugging this (based on for example what you've been doing) I could pick up working on this again, and maybe find a fix.

It's likely going to require patching, so really what I'd need to know is all the programs involved in regulating the volume control, both in gnome and alsamixer (so I can compare something that works against something that's broken). If you happen to know any of these programs (or even more specificially, the exact names of the relevant source files) could you post that here?

Revision history for this message
xtknight (xt-knight) wrote :

lomion: I appreciate your interest in it. I opened a new report here. I have spent longer but still no idea what the issue is. But I suspect very much it is a race condition between different mixers or applications reading the mixer.

See Bug 252237

gnome-settings-daemon controls the keyboard volume keys, and is affected severely sometimes (I don't know what circumstances affect 'sometimes').

gnome-alsamixer seems not to mess its own GUI up like the other programs, but it quickly messes up at least when text-mode alsamixer is open.

gnome-volume-control is the normal GNOME mixer GUI and its most common symptom is random muting, and jumping to 0 without notice. It loses control of both channels quickly sometimes when they are locked, and starts adjusting them independently/incorrectly.

alsamixer, when run only in a TTY with no desktop environment, seems to have no issues. When run under GNOME or KDE, it can experience problems.

Disabling the second CPU on one of my computers fixes the problem for that computer, with gnome-volume-control. (Opening three mixer apps concurrently still shows a problem.) Disabling the second CPU on the other computer doesn't fix the problem with gnome-volume-control ONLY open.

So, I can only assume this is some sort of condition in which two applications (maybe hidden desktop environment daemons) or threads are reading from the volume at the same time, one is failing a read, getting a zero and writing it back somehow. But I am not sure. A kernel/sound developer that knows how to properly debug it really needs to look at the problem because laypeople shouldn't have to reverse engineer the several layers of abstraction that go into the sound system. I hope to get the proper people involved to see what's going on but this seems to affect many users and configurations. I don't feel I can do any more at this point in terms of adding hooks and debugs and printfs in the code of gstreamer,alsa and gnome-volume-control as it has proven futile.

I traced some library calls by recompiling the source packages and incorporating code to save the pertinent calls to a file. ltrace wasn't too reliable.

I tried tracing some calls within and/or looking at the following files from the following source packages for Ubuntu Hardy 8.04.1.

gnome-media: gst-mixer/src/volume.c
gstreamer-0.10-plugins-base: ext/alsa/gstalsamixer.c
alsa-lib: src/mixer/simple.c
alsa-lib: src/mixer/simple_none.c
alsa-lib: src/mixer/mixer.c
gnome-applets: mixer/applet.c
gnome-settings-daemon: plugins/media-keys/actions/acme-volume.c

And tried disabling pulseaudio. The gnome-settings-daemon keyboard controls were also disabled temporarily for a test but this didn't help.

No closure has been reached by me yet on what the real problem is. A couple proposed patches for the problem (a patch for cards with similar capture/playback volume controls [15_alsa_p_c_volume.patch] or [gnome-applets-2.20.0-mixer-out-of-sync.patch]) were either applied already or had no effect on the issue that I could tell. It's possible I made an error in testing like not rebooting, doing ldconfig or letting the apps reload the new libraries.

Revision history for this message
xtknight (xt-knight) wrote :

For those who are still having the problem, can you try my new gst-plugins-base0.10 Hardy packages here?

https://launchpad.net/~xt-knight/+archive?field.name_filter=gst-plugins-base0.10&field.status_filter=published

I would like to know if it fixes the problem for you. It does for me. The keyboard controls are fixed and I believe the chain-breaking is, as well.

Revision history for this message
Richard Laager (rlaager) wrote :

I can confirm that xtknight's packages fix both problems for me.

For anyone else looking to test, you have to download and install the .debs individually, because they are now the same version as the ones for Hardy, so they won't upgrade automatically.

xtknight: I see you're removing a bunch of code with that patch. Do you have any idea what it was originally added for?

Revision history for this message
xtknight (xt-knight) wrote :

Richard Laager: I'm not really sure what it was for. It looks like some form of asynchronous update with events and callbacks to save CPU power vs continued polling. I'm waiting for a response from the gstreamer team at the moment from the bug report I filed at gnome bugzilla. http://bugzilla.gnome.org/show_bug.cgi?id=545932 They should be able to clear things up.

Revision history for this message
Sergio Zanchetta (primes2h) wrote :

It's fixed for me in Intrepid updated.

Revision history for this message
Davidiam (hectorjerezano) wrote :

It is not fixed for me in Intrepid !

Revision history for this message
Mark Grandi (markgrandi) wrote :

its mostly fixed, but sometimes it drops down to zero randomly, but then goes back to normal. its a lot more usable now, but i think some problem is still there

Revision history for this message
Sardar (ja-doma) wrote :

Solution seems to work best: https://bugs.launchpad.net/gnome-applets/+bug/126333/comments/42

The following is for metacity & ALSA users:

We need to determine correct media keys, so;
System -> Preferences -> Keyboard Shortcuts
Change shortcuts for Volume Up/Down/Mute by click in the field and then pressing the key combination (media key). Value should change from "Disabled" to something like "XF86AudioRaiseVolume" etc.

Application -> System tools -> Configuration Editor
(if not found: Alt-F2 or open terminal and type "gconf-editor")
navigate to: /apps/gnome_settings_daemon/keybindings
Change keys "volume_down|up|mute" to empty value, but before that copy the contents (correct name of your media key).

Open: /apps/metacity/global_keybindings, find empty run_command_N keys (have value "disabled"), put media-key names from the previous step. Now metacity will fire up these commands/events whey you press your media key.

Open: /apps/metacity/keybinding_commands, locate command_N entries for which you have set the key combinations in previous step. Put:

volume up: "amixer -c 0 set Master 2dB+"
volume down: "amixer -c 0 set Master 2dB-"
toggle mute: "amixer -c 0 set Master toggle"

amixer works directly with ALSA, so try these commands in command line before doing this all. You may find another way to change your sound settings, then just put that command as described above.

Compiz users: install CompizConfig manager, General Options -> General -> Key bindings
Provide key bindings and commands as described above. On my machine compiz automatically uses metacity keybindings.

Revision history for this message
Robin Sheat (eythian) wrote :

In intrepd (and I'm not sure if this is a change or not), this still happens, but only with PCM. Changing the applet slider when it's controlling PCM causes things like the LR balance to unlock, and the channels end up out of kilter, and jump around and so on. With master it moves smoothly.

Revision history for this message
Richard Laager (rlaager) wrote :

After reading the last comment, I tested with Master instead of PCM. Master is significantly smoother for me. (I'm running Intrepid now.) That said, it's not perfect. I'm still able to get the volume bar to jump around.

Changed in gstreamer:
status: Unknown → New
Changed in gnome-applets:
status: Confirmed → Fix Released
Revision history for this message
zen0 (a-neuron) wrote :

Definitely not fixed for me in Intrepid.
I have one USB audio device that has only a PCM mixer, so the workaround does not apply.
I want to assign it to a dial on my keyboard, but any adjustment will mute 1 channel, etc.
can only adjust with alsamixer-curses. good thing I prefer to use an external volume w/that device.

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

does anybody still get the issue in jaunty?

Revision history for this message
Ethan Bissett (draimus-deactivatedaccount) wrote :

This is no longer occurring for me on 9.04 beta. I have a Thinkpad R30.

Revision history for this message
Mark Grandi (markgrandi) wrote :

the sort periods i have been using jaunty i have not had this problem, most likely because there is a new volume applet?

but anyway...it appears to be fixed,.

Revision history for this message
Miguel (miguel-glug) wrote : Re: [Bug 126333] Re: Regression - Volume Control using gnome panel applet and keyboard shortcut alternates mute / % volume during sliding

For me it's working fine too.

On Thu, Apr 2, 2009 at 3:24 AM, Polygon <email address hidden> wrote:
> the sort periods i have been using jaunty i have not had this problem,
> most likely because there is a  new volume applet?
>
> but anyway...it appears to be fixed,.
>
> --
> Regression - Volume Control using gnome panel applet and keyboard shortcut alternates mute / % volume during sliding
> https://bugs.launchpad.net/bugs/126333
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

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

closing since the comments state that works fine in jaunty now

Changed in gnome-settings-daemon (Ubuntu):
assignee: nobody → Ubuntu Desktop Bugs (desktop-bugs)
status: Incomplete → Fix Released
Changed in gnome-applets:
importance: Unknown → Medium
Changed in gstreamer:
importance: Unknown → High
status: New → Unknown
Changed in gstreamer:
status: Unknown → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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