Call me crazy or weird, but I think a volume knob should do only 2 things:

1. Turn volume up or down. Turn it to 7 o'clock position and volume should be off. Turn it clockwise and volume at 5 o'clock should be at maximum. This is the way volume knobs have worked on radios since forever. See these images for examples:

http://www.flickr.com/photos/jvk/4923343/
http://www.fotosearch.com/IMR417/ie245-023/

2. Mute volume (not pause) when pressed. Note that this product does that:

http://www.coolest-gadgets.com/20070829/powermate-volume-knob/

From their website: "...is the coolest volume knob your desk has ever seen. Crank up your MP3s and CDs. Then with a push of its button, mute your music to answer the phone and handle the complaints."

Mickey, to clarify, the request from the previous bug is only referring to allowing different options for pressing the button, not when rotating it.

Agreed 100 percent.  Volume knob press should mute, not pause.  

Besides, we already have a dedicated pause button on the device...

Matt, I'm confused with comment #3. This bug isn't suggesting making volume press be pause. bug 12472 addressed making volume press mute, this bugs is about offering a choice, via the existing Shortcuts page, which Dean suggested and I agree with since many users don't care about mute.

Tom, in r6826, volume press IS pause.  So there's a bug there.

And for now I think that's all we should do.

I'm wary of any other additional functionality at this point, since volume should ALWAYS be immediately available.  Nothing worse than the phone ringing, door knocking, etc. and not being able to turn down the volume.

I'm recommending implementing mute, then pushing this bug post-7.4.

Why does there seem to be confusion? 1) The pause bug is fixed, as shown in the related bug, 2) volume IS always available, even if the button press does something else that the user wants, and 3) typically users pause when they want music to stop on most music players, so volume button as mute is probably the most unuseful button on the device, thus the suggestion to make it configurable is reasonable and is about 3 hour coding time or less since we already have the Shortcuts concept in place. Sure I can see making it not a P1 for release, but your arguments against it in comment #5 just don't make sense to me.

(In reply to comment #6)
> Why does there seem to be confusion? 1) The pause bug is fixed, as shown in the
> related bug, 

Apologies, my mistake, was reading quickly, and I had just updated my firmware.

> 2) volume IS always available, even if the button press does
> something else that the user wants, 

How so?  Maybe I'm missing something from the proposal.  How would this thing work?  FYI I'm not familiar with the "shortcuts" implementation everyone is referring to, first I've heard of it.  But if you configure your volume press to control, for example, the treble, then turning the knob changes the treble, not the volume, right?

If it's a case of toggling, i.e. multiple presses toggle between volume, bass, treble etc. then same problem, unless the knob "times out" after a few seconds and reverts to a volume control.  Is this what is being suggested?

and 3) typically users pause when they want
> music to stop on most music players, 

What are you basing this assumption on?  We've never had a mute button before to my knowledge, or a stop button for that matter.  So of course people are pressing pause - it's the only way to stop music!  That doesn't mean people wouldn't use a mute button if it wasn't available.

Also, the "pause to mute" argument is an argument for doing nothing at all with the volume press, not an argument for adding functionality just because we can.

>so volume button as mute is probably the
> most unuseful button on the device, thus the suggestion to make it configurable
> is reasonable 

OK, here's my general problem with the original feature request.  It wasn't based on a user need (at least not the way it's been worded in discussions), it was a case of "we have this extra button available; what can we make it do?"  It's the exact wrong way to make design decisions IMO.
There's no rule saying we have to make that button do ANYTHING if it doesn't improve the user experience.

This kind of thinking is what has gotten us into problems like the "use play for navigation" issue etc.

this is an administrative shuffle on priority fields to help make better judgment on the top end of the priority list. P4->P5, P3->P4, and P2->P3.

*** This bug has been marked as a duplicate of bug 14518 ***