Okay, I just got a new Logitech USB headset, it plugged and played immediately, but the Speaker channel is apparently somehow broken. I try to keep them linked together while switching the volume, but then it unlinks and the left headphone just dies. Is there some wierd problem that can't be fixed or is it just a bug, etc.?

Hello?? Can ANYONE help?

Try upgrading to the latest kernel and/or latest version of ALSA.

[RANT]Sound support in Linux for anything but generic hardware is hit or miss. Things should get better now that the kernel debugger is becoming part of the mainline kernel, but Linux really needs the equivalent of WinDbg before you will see really good support for non-generic hardware. As a person who develops drivers for both Windows and Linux, I can tell you it is 10 times harder to develop for Linux. This is the real reason companies do not want to write open source drivers: They cost 10 times as much in software developer salaries.[/RANT]

No latest version of Alsa, doing dist-upgrade to get the new kernel image... Hold up, let me restart.
[edit]
Apparently, that's not it. It's something to do with the GUI's stereo channel. I can start up alsamixer and it works seamlessly. I'm going to reinstall the gnome-volume-manager package and see if that works.

Alright, my conclusion:
The GUI is messed up, and i'm ignorant about using the TUI for the alsa mixer. Don't go about buying another pair of USB headphones (God, that is such an oxymoron...) if you don't want to go into terminal in order to bump your volume up one percent when you've already got a volume control sitting on your right (or left) ear(cord).

If alsamixer works, I would dump the gnome GUI.

That's nothing but FUD.

[SOAPBOX]
What the open source community wants more than anything, is open and accurate technical specifications on how to communicate with said hardware, so that they can write their own drivers for it. Failing that, well-documented source to a driver for any platform would be extremely helpful. The only reason this information is not forthcoming from hardware vendors is that it would conflict with business goals of vendor lock-in and protection of intellectual property.

The only reason Linux (or *BSD) drivers sometimes cost 10 times as much to develop than Windows drivers is the reverse engineering required due to the hardware vendors' inability or unwillingness to to release specs for their hardware.
[/SOAPBOX]

I have just bought a pair of Logitech USB desktop speakers, and the volume control on them does not work. I have tried KMix, QAMix, and alsamixer. In all three cases, the mixer program freezes up when I try to change the volume, and I have to unplug the speakers from the USB port and plug them back in to get them to work again. Does Logitech use the same hardware in their desktop speakers as in their headphones? Or am I posting in the wrong thread here?

The volume control (on the USB desktop speakers) works just fine with this one. (It even docks in my KDE system tray with alltray.) So what is the gnome alsamixer doing differently from the other three mixers?

It might be FUD if I were not a kernel device driver writer. Are you a kernel device driver writer? Have you written drivers for both operating systems?

I have written drivers for both operating systems and I had accurate technical specifications. The Linux driver took 10 times longer because, as I previously mentioned, it is 10 times harder when all you have for debugging is printks.

Come back for more after you have written drivers for both systems.

The FUD is when the asserted difficulty of writing Linux drivers is used as an excuse to refuse to release technical specs or any other useful information on how to interoperate with a hardware product.

The difficulty (or not) of writing a Linux driver has nothing to do with whether the drivers themselves are open-source or not, whatever OS they may be running on, and it has nothing to with whether or not a company chooses to release specs for their hardware so that others may write drivers for it if they so choose.