Here is a summary of commonly reported symptoms when a USB audio device is connected (there are still many reports on XP and a few on Vista/7)

a) Input and output sliders are ganged together
b) Input slider does not control the input of the USB device, but is not greyed out/maximised as intended when it has no control
c) output slider does not control the motherboard sound device
d) Input slider does not control the motherboard sound device (but is greyed out/maximised) and the selector for the motherboard device may disappear 

Gale has problems c) and d) only on XP SP3 with Trust USB soundcard (with or without specific drivers) and Ion USB turntable. These problems do not occur for me on Win 7 x64.  Peter has a) b) and c) when Edirol USB device connected (with or without the specific Edirol drivers).

(In reply to comment #1)

If the Meter Toolbar was monitoring input, PrefsDialog can be opened, but then PrefsDialog::OnOK() was not calling StopStream() and AudioIO::HandleDeviceChange() then will no-op. Made OnOK() stop the stream before calling AudioIO::HandleDeviceChange().

This may have been some of the occasions of bug 29, where user changed device while monitoring, but the AudioIO::HandleDeviceChange() code did not actually change the device, so it look like the user had specificied the motherboard/sound card default device, but Audacity was still using the USB device.

(In reply to comment #1)

In looking at this bug, I found that ASIO support was never added to PortMixer, so their output is always emulated and input slider is disabled. 

For Behringer GuitarPort, the driver reports that it supports MME and DirectSound, but it doesn't work -- only ASIO works. I don't see any way we can fix a bad driver that says it has capabilities it does not. 

Other MME and DirectSound settings work fine, so I cannot replicate the bug with that device. Will try some others.

I can replicate this using a RME Fireface 400 (firewire, not USB), using MME on Vista x64.

I don't seem to have the option to use ASIO - in the device prefs MME is the only host, but maybe this is something I need to setup.

The sliders have no effect.  Some debugging shows Portmixer is returning the correct slider values, so I suspect the bug to be in portmixer/portaudio code.

(In reply to comment #4)
> I don't seem to have the option to use ASIO - in the device prefs MME is the
> only host, but maybe this is something I need to setup.
Thanks for your recent fixes, Michael. We don't distribute Audacity with ASIO support due to licensing, but it would be good to test with ASIO enabled. We do distribute with Windows DirectSound support so that must be enabled. You can read how to compile Windows with ASIO and DirectSound support here:
http://code.google.com/p/audacity/source/browse/audacity-src/trunk/win/compile.txt

Edgar and I have both failed recently to compile SVN HEAD on Win 7 with ASIO support so I'd be interested how you get on there. 

Is this bug really Windows only? I don't recall any reports outside Win, but I don't think anyone has tested it on Mac/Linux.

(In reply to comment #5)
On Mac PPC 10.5.8 Audacity 1.3.13 Dec 2 2010, the presence of a USB input device does not appear to cause the input or output sliders to behave incorrectly when Prefs > Devices > Recording is set to "Built-in Audio" (the Mac equivalent of line input).

(In reply to comment #5)
Commenting here, as this seems to be related in that selecting a device (through the input selector on the mixer toolbar) that has no input control causes the input slider to behave incorrectly, which is similar to selecting a USB input device that has no input control.

On Mac PPC 10.5.8 G5 with optical digital inputs, Audacity 1.3.13 Dec 2 2010
Set Prefs > Devices Playback > Built-in Audio, Recording > Built-in Audio
Input selector is available in mixer toolbar
With input selector = Line In, input slider operates correctly
Switch input selector to Digital In
Input slider is not greyed but snaps back to 0 when manipulated
Open Prefs > Devices and click OK
Input slider is maxed out and greyed (correct)
Switch input selector to Line In
Input slider remains greyed
Open Prefs > Devices and click OK
Input slider is active.

More looking makes me think this is not a portmixer bug but a windows issue.
When I go to the windows mixer/sound control and change the volume, it changes in audacity and vice versa.  So this means portmixer is doing the right thing at least on the system level.  The problem is windows not actually executing the volume control.
Also, using other (non-audacity) apps and system sounds aren't affected by the windows sound level.

Is it possible to fix this bug by emulating volume in all cases on win, or at least degrade the severity?
I can and will look into some workarounds, perhaps by patching portmixer to use a different api.

(In reply to comment #7)
> this seems to be related in that selecting a device(through the input selector > on the mixer toolbar) that has no input control causes the input slider to 
> behave incorrectly, which is similar to selecting a USB input device that has 
> no input control.
Seems a different issue? Bug 29 doesn't only affect external devices without a mixer (such as a USB turntable). 

Forgive ignorance of Mac, but why does the built-in Mac digital-in lack an input control? You mean it can't be controlled even in Audio MIDI Setup? 

Would be interesting to test with any Macs that actually have a second or separate analogue input - are there still any? Possibly switching any input in the selector gives incorrect slider behaviour until refreshed in Prefs? 

Presumably when you switch using the input selector, the correct input is immediately selected (just the slider behaviour is wrong)?

(In reply to comment #9)
> Forgive ignorance of Mac, but why does the built-in Mac digital-in lack an
> input control? You mean it can't be controlled even in Audio MIDI Setup? 

Correct. Nor in the Sound Prefs panel. It's a digital (S/PDIF optical) input, similar to a USB audio input in that no volume control is possible. I suppose the system could scale the digital input, but it doesn't.

> Would be interesting to test with any Macs that actually have a second or
> separate analogue input - are there still any? Possibly switching any input in
> the selector gives incorrect slider behaviour until refreshed in Prefs? 

I tested this on my PowerBook, which has analog line in and internal mic. Switching between the two does not cause incorrect input slider behaviour. It is the switching to and from a device that does not have input control.

After enabling the Devices toolbar, it is possible to refresh the input slider by simply clicking and releasing on the Device toolbar input drop-down menu (without changing its setting).

Note that the Input Selector cannot be used to switch to the USB Audio CODEC. On Mac it can only be used to switch between the various devices supported by the "Built-in input". Switching to USB Audio CODEC in Audacity Prefs : Devices : Recording causes the input selector to (correctly) disappear, and the input slider to be disabled.

> Presumably when you switch using the input selector, the correct input is
> immediately selected (just the slider behaviour is wrong)?

Correct.

(In reply to comment #10)
> After enabling the Devices toolbar, it is possible to refresh the input slider
> by simply clicking and releasing on the Device toolbar input drop-down menu
> (without changing its setting)
I seem to recall the answer may be Mac-dependent, but does Mac Device Toolbar or Prefs ever display the line-in or internal mic, or only "Built-in Audio" as a single choice plus any external devices?    

I know you said having a USB device connected didn't seem to cause issues when Built-in playback and recording devices were selected in preferences, but is that also true if you switch back and forth between your USB device and Built-in audio? Is your USB device a non-mixer device or one where the input control is assumed not to work?

(In reply to comment #11)
> I seem to recall the answer may be Mac-dependent, but does Mac Device Toolbar
> or Prefs ever display the line-in or internal mic, or only "Built-in Audio" as
> a single choice plus any external devices?    

Yes, devices prefs and device toolbar only show "Built-in Audio" or other devices such as SoundFlower, a USB device or an "Aggregate Device" created in Audio Midi Setup.

> I know you said having a USB device connected didn't seem to cause issues when
> Built-in playback and recording devices were selected in preferences, but is
> that also true if you switch back and forth between your USB device and
> Built-in audio? Is your USB device a non-mixer device or one where the input
> control is assumed not to work?

Don't know what you mean by "non-mixer device", but any device that shows up in System Prefs : Audio : Input with no input control correctly disables the input slider in Audacity. In these cases the Input Selector in Mixer Toolbar also disappears, but probably because there is no "input" to select, as there is with "Built-in Audio". 

The key seems to be that going through Devices Prefs or Device Toolbar causes a refresh of the input slider that using the Input Selector doesn't do. I thought this might give some insight into this bug.

Perhaps we should raise a separate P4 for this issue as it is Mac specific, has a simple workaround, and is likely to affect very few Mac users (how many have optical digital connections to their Mac?).

(In reply to comment #12)
> Don't know what you mean by "non-mixer device", but any device that shows
> up in System Prefs : Audio : Input with no input control correctly disables 
> the input slider in Audacity. In these cases the Input Selector in Mixer
> Toolbar also disappears, but probably because there is no "input" to select,
> as there is with "Built-in Audio". 
>
> The key seems to be that going through Devices Prefs or Device Toolbar 
> causes a refresh of the input slider that using the Input Selector doesn't
> do. I thought this might give some insight into this bug.

A "non-mixer device" is one (like a USB turntable or many interfaces) where there is no choice of inputs to be made, and so Audacity Mixer Toolbar input selector should grey out or possibly disappear. The concept of such a device having no input slider to control its volume is unheard of (to me) on Windows. Is that what you mean by "no input control"?

What USB device are you connecting? Does it have a choice of inputs and if not, does it lack any way in the system to control its input level? What I was also asking was if you switch back and forth between this USB device and Built-in audio, if the slider of the built-in input you happen to switch to behaves correctly.

Yes this looks completely separate from Bug 29 but I'm trying to be sure there is no problem switching between USB devices and the built-in input and then the built-in inputs not being refreshed.

(In reply to comment #13)
> A "non-mixer device" is one (like a USB turntable or many interfaces) where
> there is no choice of inputs to be made, and so Audacity Mixer Toolbar input
> selector should grey out or possibly disappear. The concept of such a device
> having no input slider to control its volume is unheard of (to me) on Windows.
> Is that what you mean by "no input control"?

See this page
http://manual.audacityteam.org/index.php?title=User:Billw58/OS_X_and_USB_input_devices

> What USB device are you connecting? Does it have a choice of inputs and if
> not, does it lack any way in the system to control its input level? 

Behringer UFO-202 phono/line USB adapter. It has no choice of inputs and it does not have any way in the system to control its input level.

> What I was also
> asking was if you switch back and forth between this USB device and Built-in
> audio, if the slider of the built-in input you happen to switch to behaves
> correctly.

In that case the slider behaves correctly.

> Yes this looks completely separate from Bug 29 but I'm trying to be sure there
> is no problem switching between USB devices and the built-in input and then
> the built-in inputs not being refreshed.

To reiterate: switching inputs with the Device toolbar or Devices Prefs refreshes the input slider, switching inputs with the Mixer toolbar input selector does not.

Okay, I asked around and no one seems to know, as it appears to be a hardware vendor to windows issue (since the windows system mixer is set correctly by audacity despite the hardware not actually making the change)

There is also no way to tell which devices will work and which will not; a capabilities query via the IAudioEndpoint interface says that it supports volume control for my device which doesn't work.

So will it be acceptable if we just emulate the volumes for all devices on windows?  Although quality is one concern, the other thing is that the changes will not be reflected by the system mixer, which will have a cumulative effect for the devices that work if the user changes it outside of audacity.

The other option is to look at some other open source project that does this with the desired behavior, if it exists, and is open source.  Anyone know of one?

(In reply to comment #15)

> Okay, I asked around and no one seems to know, as it appears to be a hardware
> vendor to windows issue (since the windows system mixer is set correctly by
> audacity despite the hardware not actually making the change)

Thanks. Saw that thread on PortAudio list. 


> 
> There is also no way to tell which devices will work and which will not; a
> capabilities query via the IAudioEndpoint interface says that it supports
> volume control for my device which doesn't work.

Yeah, drivers for Windows are historically (traditionally, even!) flaky about adhering to specs.


> 
> So will it be acceptable if we just emulate the volumes for all devices on
> windows?  Although quality is one concern, the other thing is that the changes
> will not be reflected by the system mixer, which will have a cumulative effect
> for the devices that work if the user changes it outside of audacity.

Well, the bug description says it happens for any device, but as reported above, it works correctly for at least one device (Behringer GuitarPort), so I don't like the idea of emulating for devices whose drivers respond correctly, because of the problems you mention. 

I've got some other devices to test, so I'll add results. Are we sure it's really even a majority of devices? We have so many users, this could be widely reported, but over a small range of devices.

One way to deal with it would be to blacklist the devices/drivers/manufacturers (whichever is generally the broadest category) we know cause the bug to appear, and emulate for them. Do we have any ideas of numbers? 


> 
> The other option is to look at some other open source project that does this
> with the desired behavior, if it exists, and is open source.  Anyone know of
> one?
> 

Not I. I don't see how they could fix drivers from third parties in any general way.

"Any" device in the bug description means "any of the user's devices" i.e. connect an external device and then while it is connected the input/output sliders for all the user's devices are broken. This is a problem e.g. you can no longer properly control the mobo sound from Audacity while you have the USB device connected.

Looking at the raw reports (where an external device has been named), most of the named devices are different (so, something like 25 different external devices from about 18 manufacturers).       

Michael wrote:
> When I go to the windows mixer/sound control and change the volume, it
> changes in audacity and vice versa.  So this means portmixer is doing the
> right thing at least on the system level.  The problem is windows not
> actually executing the volume control. 
So are you saying when you move the Audacity slider the volume level changes but the system slider doesn't move; or the Audacity/system sliders interact but the volume level doesn't change when using the Audacity slider?

I've asked a few users about this in the last week or so and mostly they say when the external device is connected, the Audacity sliders for the motherboard device neither move the system sliders nor affect the volume. That's true for me on XP with two different models of Trust USB Soundcard. One user who also has a PCI card says that when he has a M-Audio Pre connected, the Audacity/system sliders for the PCI card interact but using the Audacity slider doesn't actually change the volume (changing it with the system slider does change the volume); the sliders for the mobo sound don't interact and the Audacity slider has no affect on the sound.  

Also given some people say this bug is not in 1.2.6 (true for me, too) that suggests it could be a PortAudio problem.   

Michael wrote:
> Also, using other (non-audacity) apps and system sounds aren't affected
> by the windows sound level.
Can you explain that in more detail? 

To compare if other apps like Audacity have this problem they would have to be not using emulation? 

Also it's a concern in comment 1 that some people find the Audacity input slider for the external device does not grey out when in reality it does not control the input level.

>> When I go to the windows mixer/sound control and change the volume, it
>> changes in audacity and vice versa.  So this means portmixer is doing the
>> right thing at least on the system level.  The problem is windows not
>> actually executing the volume control. 
>So are you saying when you move the Audacity slider the volume level changes
>but the system slider doesn't move; or the Audacity/system sliders interact but
>the volume level doesn't change when using the Audacity slider?

In my case moving the audacity slider causes the system sliders to move, but there is no change in the volume level coming out of the device.  Now that I have ASIO and DirectSound, I can verify that the volume slider is disabled for the same device in ASIO/DSound, but not in MME, so this may be an MME bug about not report the correct capabilities.

>Michael wrote:
>> Also, using other (non-audacity) apps and system sounds aren't affected
>> by the windows sound level.
>Can you explain that in more detail? 

If I change the system slider (accessible in the taskbar) for another app, like VLC or even the System Output, the volume output from the device does not change.

>
>To compare if other apps like Audacity have this problem they would have to be
>not using emulation? 

Yes, unfortunately they have to not use emulation in order to have any value for us.

So it seems this is a seperate problem from what you are describing, but still a part of this bug.
In the cases you mention is the problem the same for ASIO/DirectSound?
I am becoming more skeptical that we can resolve this bug.

Now flagged as a regression (on 1.2.6) following a comment by Peter.

(from David Bailes & Peter Sampson) 1.2.4b, 1.3.7, 1.3.8 and 1.3.9 - all fine; 1.3.11 onwards all show the errant behaviour

James wrote:
> Michael in comment 18 is suggesting this is a bug that cannot be 
> progressed - we are not using emulation and these are USB sound device 
> driver limitations. Then we need to rename this bug to something like
> "Some Windows USB devices do not respond to changes in system volume 
> settings"
While that statement is correct in itself (but far more commonly, some USB devices on any platform will not accept their input level to be controlled by Audacity), it is not what this bug is about. 

The bug is that when you have a USB device connected, the Audacity sliders for the mobo device (and in some cases the USB device also) will not work correctly. Remove the USB device and the sliders for the mobo device then work correctly. Uninstall the mobo device and the sliders for the USB device work correctly (I can confirm that as have several of my correspondents). I think it is an Audacity (PortAudio?) issue to do with interaction of external and mobo devices. 

Although Michael finds when the USB device is connected, the Audacity output slider moves the mobo system slider without affecting the sound level, the majority of reports suggest the mobo system slider does not move, and that is why the sound level does not change. The system slider does affect the USB device's sound level. 

If I include the borrowed Logitech USB headset in my tests then I can reproduce a), b) c) and d) in comment 1 on Win XP in 1.3.12/1.3.13 but not in 1.2.6 or 1.3.9, or in CoolEdit Pro or Goldwave.

The changes made to address bug 11 affect this bug.  A possible fix is in.
See comment 81 of that thread.

Just a note that if the default device is changed we should probably reopen the mixer to get access to the change in slider.
I don't think it is a problem to do this in StartPaStream() in AudioIO.cpp (currently we don't.)
I came across this working on bug 11 and just noting here.

Report received for Microsoft VX1000 USB webcam (unknown version of Windows, probably 1.3.12 Beta). When connected the webcam usually doesn't record but might do if the Audacity input slider is moved. After it's connected, it removes the built-in sound device from Devices Prefs, leaving only the USB webcam, but the built-in device is still selectable from Device Toolbar. User will be asked if they can try 1.3.13.

I forgot to change the status on this.  Please let us know if the severity/reports have dropped since 1.3.13.

@Bill: of course we no longer have the Mixer Toolbar input selector, but on Mac PPC 10.5.8 G5 do you still have your issue in comment 7 i.e. switching to/from a device that does not have an input control causes the input slider to misbehave/not be greyed when it should be? And can you retest switching between digital in (that has no input control) and line in (that does) without any USB devices connected (so we can see if the USB device is the problem).     

(In reply to comment #25)
> Please let us know if the severity/reports have dropped since 1.3.13.
There seem to have been significant improvements here. At least six people who had the issues a), c) and d) in comment 1 in 1.3.12 don't have them in 1.3.13 e.g. Peter Sampson and the Microsoft VX1000 USB webcam person in comment 24.

But I have seen seven Win XP reports since 1.3.13 release that sound like a), c), d). I think a few could be valid 1.3.13 problems (USB tape recorders or turntables) but the others I'm still trying to get more information. The reports are for "latest 1.3 version" which can mean anything and I don't know if the problem is confined to MME or not.  

b) Input slider of USB device (and sometimes mobo device) not greyed out when it lacks control of the device - this has at least 18 reports since 1.3.13 release on Vista and 7 as well as XP. But if the mobo input slider is affected it greys out properly when the USB device is removed. 

I am going to take another 36 - 48 hours to see if we've done enough to demote this to a P3 that either covers only b) or still includes a), c) and d) as well. Any new testers on XP would be appreciated. I hope by then I can retest myself on XP with several USB devices (I have not tested there since your relevant commits). I hope also some of the other XP people may have responded by then.

(In reply to comment #26)
> on Mac
> PPC 10.5.8 G5 do you still have your issue in comment 7 i.e. switching to/from
> a device that does not have an input control causes the input slider to
> misbehave/not be greyed when it should be? And can you retest switching
> between digital in (that has no input control) and line in (that does)
> without any USB devices connected (so we can see if the USB device is the 
> problem). 

1.3.14 July 1 2001 Mac nightly

Start with initialized cfg
Start with analog line input chosen in system prefs and volume set to 75%
No USB Audio interface connected

- In Device toolbar, inputs shows "Built-in Audio: Line In"
- Input slider is active and set to 75%
Change to "Built-in Audio: Digital In"
- Input slider greys outs at maximum
Change to "Built-in Audio: Line In"
 - Inpput slider un-greys at 75% volume
Change to "Built-in Audio: Digital In"
Quit and re-launch Audacity
- Device toolbar input selector shows "Built-in Audio: Digital In" and Input slider is greyed at maximum
Change to "Built-in Audio: Line In"
 - Input slider un-greys at 75% volume

Quit Audacity, connect a USB audio interface, and repeat the above, substituting "USB Audio CODEC" for "Built-in Audio: Digital In".

The above repeats exactly.

So this issue appears to be resolved.

After much testing with various USB devices /reviewing reports / making sure users have 1.3.13 and best possible drivers, I think we can say a), c) and d) in comment 1 are fixed. The very few people who still have these issues seem to have questionable drivers for motherboard or USB device or are using devices outside the supported operating systems.       

That still leaves c) as per comment 26 "Input slider of USB device (and sometimes mobo device) not greyed out when it lacks control of the device". This has at least 25 reports since 1.3.13 release on Vista, 7 and XP. But if the mobo input slider is affected, it greys out properly when the USB device is removed. 

This bug is now DEMOTED to P3 and concerns this issue c) only. Bug title changed from "Input and/or output sliders operate incorrectly for any device when an external device is connected" to "Input slider not greyed out when it has no control of input device." It appears to be a partial regression on previous Betas e.g. for my oldest USB turntable the Audacity input slider is correctly greyed out in 1.3.10 but not in more recent Betas than that.     

A wide variety of USB devices are involved. Symptoms where Audacity slider not greyed:

1) Windows slider controls input level but Audacity's input slider does not move the Windows slider. Reported a lot with first generation USB turntables and various older headsets. Host choice makes no difference. 

2) No Windows input slider appears (occasionally, a Windows slider is reported on Vista/7 but this is again not controllable by Audacity). Where there is no Windows slider the Audacity slider typically does nothing, but sometimes does apply software gain. Affects Edirol UA-1 series interfaces, Behringer interfaces e.g. UCA 202, various headsets or USB mics on some machines (but  the devices all have software or hardware controls of their own). Host choice makes no difference.  

I assume Audacity can't control input level of a device that has no Windows slider, correct? So all Audacity should do is grey its input slider. Note that people with e.g UCA 202s which have no input control on the device quite often ask that Audacity "should" be able to apply software gain just for the convenience.  

3) As per comment 18 there are much rarer symptoms where moving the Audacity slider causes the Windows slider to move, but volume level of the device is not affected (this is believed a device vendor/Windows issue). In these cases it seems (usually but not always) that only the MME host fails to disable the input slider (ASIO and Direct Sound do disable it). @ Michael, I'm not clear here - is this issue only with the input slider or does the Audacity output slider move the Windows slider but not affect the device level? If so, should Audacity's output slider grey out if it has no control - I thought not?

I only have one USB device to test with Edirol UA-1EX

This Bug would appear to still be extant on Mac.  The sliders are not grayed out and thus look active  but they have no control over the device.  The output slider can be moved, the input slider cannot be moved.

However on my W10 laptop it appears to work fine with the sliders not grayed out and available to control the device.

(In reply to Peter Sampson from comment #29)
With my Behringer UFO-202, with Audacity 2.2.0 alpha on Mac OS X 10.11.4, I observe:
* when set as input (USB Audio Codec) input slider is not greyed, but gives the "(unavailable: use system mixer)" tooltip, and does not operate
* when set as output, input slider operates and controls the output volume of the UFO-202

I believe the above is correct behaviour on Mac. The input slider may not be greyed but it gives the correct tooltip and does not operate.

Anyway, the release note is for windows.

Works for me and has long done so (and way back it did not work for me)

And Bill is happy with Mac behavior.

Plus I can recall no posts about such like of the Forum for a very long time.

Therefore I am going to close this off