Do you mean that there is a wxChoice combo box, but there is only one option there?  The mac has this issue as well.

Update per Michael's comment that it's on OS X, too.

(In reply to comment #2)

This bug description didn't make complete sense to me, and "See here and how it might look" didn't have a link. So I found the thread discussing it, now added to the URL above. 

The thread is about, basically, duplicating the HOST, Playback, and Recording device menus from the Devices tab of preferences -- which are already in the Device Toolbar. So that seems more like a feature request, reworking what's where, than a bug. It's certainly easy enough to turn the Device Toolbar on by default, though I think it takes up valuable screen space for preferences accessible elsewhere, that most users will not change very often, if ever.

Is there an actual bug here? In what way are things different on Vista/7?

(In reply to comment #3)
See http://wiki.audacityteam.org/wiki/User:BillWharrie/Device_and_Input_selection_on_Mac for Mac illustrations and a discussion of this issue.

Summarizing:
On Vista/7 the Host, Device and Input are aggregated in the Device Toolbar and Devices Preferences. In this case the Mixer Toolbar input selector shows nothing, or something unhelpful such as "Master Volume". The user must go to Devices Preferences to select their input, and must enable Device Toolbar to see what input they have chosen.

On Mac Intel the Host, Device and Input are aggregated in the Device Toolbar and Devices Preferences. If one of the "Built-in" devices is chosen, the Mixer Toolbar input selector duplicates the Input selection in Device Toolbar, but only one choice is available. If an external device (such as a USB interface) is chosen in Device Toolbar, the Mixer Toolbar input selector disappears.

On Mac PPC and WinXP, the inputs are not aggregated with the Host and Device in the Device Toolbar, and the Mixer Toolbar input selector allows choices of inputs providing the device has multiple inputs.

So this may not indeed be a "bug", but the behaviour is an impediment to new users on Vista/7 and Mac Intel systems getting up and running, since there is no obvious way to select the input they want.

The simple expedient of enabling the Device Toolbar by default (and docking it either above or below the Mixer Toolbar) would help in the short run.

I regard it as a "bug" in the sense that we developed a very useful feature to enable input selection by default directly in the interface. Win Vista and later broke that (as to a lesser extent did Intel Mac) and our interface has not kept step. At the same time we have Device Toolbar which (on other OS'es) is a space-consuming duplication of Mixer Toolbar (except that it also lets you change host and device); yet neither Mixer Toolbar or Device Toolbar let you change recording channels, so still make you use Preferences/ rely on finding them. It's a mess, IMO.    

Fundamentally, Audacity has a very bad press for "not letting you easily change inputs" on modern OS'es. While some of the problem is down to the OS (Windows Vista and 7 hide all or most of the inputs by default), IMO Audacity would receive even worse press if 2.0 was released having done nothing at all to help the problem.  

Three other thoughts I'd like to throw in - is it possible to:-

a) suppress the Mixer Toolbar Input Selector and dock Device Toolbar to right of the Mixer Toolbar input slider? 

b) In Device Toolbar, truncate the text for host when too long e.g. replace "Windows DirectSound" with "DirectSound"; or reduce the combo box width so that it only displays the full text when you drop the menu down?

c) provide a button to access the OS Control Panel - Total Recorder (on Windows) provides a button to do this for fairly obvious reasons

(In reply to comment #5)
> neither Mixer Toolbar or Device Toolbar let you
> change recording channels

With the addition of recording channels to Device Toolbar it would completely replicate Devices Preferences. Perhaps we could then do away with that preference? There's a trade-off between "screen real estate" and having to go to Devices Preferences to change inputs. I'd rather have the Device Toolbar.

> a) suppress the Mixer Toolbar Input Selector and dock Device Toolbar to right
> of the Mixer Toolbar input slider? 

Not good on PPC Mac, as the Input Selector is needed for "Built-in Audio" choices in Devices Toolbar. Not good on XP? What about Linux?

> c) provide a button to access the OS Control Panel

+1

(In reply to comment #6)
>> neither Mixer Toolbar or Device Toolbar let you
>> change recording channels
>With the addition of recording channels to Device Toolbar it would completely
>replicate Devices Preferences. Perhaps we could then do away with that
>preference? There's a trade-off between "screen real estate" and having to go
>to Devices Preferences to change inputs. I'd rather have the Device Toolbar.
The original idea for a "comprehensive fix" was to have Mixer Toolbar aggregate <host/device> with <input> for all OS'es then do away with Device Toolbar altogether (which isn't easy to fit in, hence the reluctance to turn it on). Aggregated Mixer Toolbar also gives the older OS'es a better "one step" method of choosing inputs even if they have extra devices. If Mixer Toolbar then had "recording channels" and the whole toolbar was accessible you would not need to go into Devices Prefs at all. 

>> a) suppress the Mixer Toolbar Input Selector and dock Device Toolbar to right
>> of the Mixer Toolbar input slider? 
> Not good on PPC Mac, as the Input Selector is needed for "Built-in Audio"
> choices in Devices Toolbar. Not good on XP? What about Linux?
Same on Linux - this "temporary fix" would have to be iffdeffed somehow so PPC Mac, XP and earlier and Linux carried on as now displaying the Mixer Toolbar input selector. It was just an idea to reduce the screen estate penalty of displaying Device Toolbar for the newer OS'es.

(In reply to comment #7)

>> neither Mixer Toolbar or Device Toolbar let you
>> change recording channels
> 
> With the addition of recording channels to Device Toolbar it would completely
> replicate Devices Preferences. Perhaps we could then do away with that
> preference? There's a trade-off between "screen real estate" and having to go
> to Devices Preferences to change inputs. I'd rather have the Device Toolbar.

+1, Bill. Better to show Preferences in commands/controls vs Prefs dialog, not both. Simplify.

(In reply to comment #8)
> +1, Bill. Better to show Preferences in commands/controls vs Prefs dialog, 
> not both. Simplify.
Once everything from Devices Prefs was available in commands/controls and accessible to VI people, the only other thing to consider would be if people turn off Mixer Toolbar/Device Toolbar to give more space to work (using the OS to control levels) so would still appreciate access in Prefs for device/host choice. I don't think this really matters as long as there are shortcuts to change device/host, but there aren't now - the only shortcuts are to Mixer Toolbar. But to me the worse duplication is Mixer Toolbar/Device Toolbar.

I would like to fix this, but I'm not sure exactly what the consensus is.
From the discussion I get:
1. Remove the device selection from the mixer toolbar
2. Remove the device preferences.
3. Turn the device toolbar on by default.

I'm not sure if step 1 is desired or not, but my personal feeling is that the device selection should be removed if it duplicates functionality.

(In reply to comment #10)
Michael:
My understanding is that there is a hierarchy of host / device / input. What is displayed in the Mixer Toolbar Input Selector is the input choice. Some devices support multiple inputs and some do not. Apparently Win Vista/7 and Mac Intel aggregate the device and input, while Win XP, Linux and Mac PPC do not. So it seems to me that for the interface to be consistent across all platforms Audacity would need to do the "aggregation" of device and input itself when the OS does not, and present those choices through the Device Toolbar. In this case the Mixer Toolbar Input Selector would be redundant. The addition of the "Recording / Channels" dropdown from Devices Preferences to the Device Toolbar would then allow the removal of Devices Preferences.

So, if the above could be implemented, I would agree with your points 1, 2, and 3.

(In reply to comment #11)
Doing away with Device Toolbar and having *one* toolbar for selection of output and input device, output and input level plus input channels seems the better solution to me if it's possible. I understand the "aggregation" is the difficult part, but if it's easier to do as separate toolbars (Device Toolbar for device and channel selection, and Mixer Toolbar only for level control) I suppose it's a second best. If we have the two toolbars, then clearly Device Toolbar has to be on by default.

Thanks Bill, I think I get it.  I'm working on a patch now that aggregates host/device/source into the device toolbar.  If we need to move it to a back to the mixer toolbar it shouldn't be hard.

Gale: The reason I prefer to remove the device selection from the mixer toolbar is that it allows for more user-selectable combinations.  If they want a mixer with device selection they can turn both on at roughly the same screen real estate.  If they don't want either they can turn it off.  What is the motivation for putting everything in the mixer toolbar?
 
Also if we remove the prefs pane we'll need to add the number of input channels selection box to take to whatever toolbar, right?  So this means it gets even bigger.

(In reply to comment #13)
>What is the motivation for putting everything in the mixer toolbar?

I think what Gale is getting at is something like this mockup

http://homerow.net/audacity/mixer3.png

where the output and input device choices are clearly linked to the output and input mixer sliders. But I agree that it probably wouldn't save any screen space, and removes the option of turning the Device Toolbar off once you've made your choices.

> Also if we remove the prefs pane we'll need to add the number of input channels
> selection box to take to whatever toolbar, right?  So this means it gets even
> bigger.

I think it's not so much a case of wanting to get rid of a prefs pane as it is a case of putting the input channels choice in the user's face. If the Device Toolbar is going to be on by default, the stereo/mono choice might as well be there. If the user can switch between a mono mic input and a stereo line input in the Device Toolbar, it seems awkward to send them to the Devices Prefs to change the number of input channels.

(In reply to comment #14)
>What is the motivation for putting everything in the mixer toolbar?

Yes Bill has hit the main reason on the head. One of the problems with the Mixer Toolbar was that you couldn't see what host and device the input choice and the levels related to. Although having an "on-by-default" Device Toolbar helps, the linkage is less clear (though almost as clear if you had Mixer Toolbar and Device Toolbar side by side). 

It seems to me that if you have everything in Mixer Toolbar you will save 68 px for the extra speaker and mic icons and the extra grab handle. Apart from that, I think it's just less confusing than splitting what it is really part of the same "thing". Another consideration is that Mixer Toolbar is well known to existing users. Device Toolbar is not (remember, many users are still on 1.2).

The point about being able to turn off Device Toolbar once have decided on the device and input selection is a good one, though I suspect many people will want to toggle Device Toolbar on and off a lot. This is not easy to do at the moment (an awkward route through to the bottom of the View Menu, or you need to discover that you can add a shortcut to toggle it). Is there a widget you could use in Mixer Toolbar that when clicked, showed/hid the Device choice combo? 

Re the design for aggregation, a structure with the Hosts on one line would considerably reduce the width needed. Also I strongly dislike the current scheme in Device Toolbar where the Device is given in brackets and the devices are *not grouped together*  - see the images at http://manual.audacityteam.org/index.php?title=Device_Toolbar.  

Something like this looks neater to me (though you would have to decide if it is acceptable not to show the host once the selection has been made). For screen reader acceptability you could ask David B.    

MME 
  Realtek Line In
  Realtek Microphone
  USB Audio Line In
  USB Audio Microphone
Windows Direct Sound
  Realtek Line In
  Realtek Microphone
  USB Audio Line In
  USB Audio Microphone

If we want to show the Host in the selected item then I think you can use sensible truncation both in the item and in how much of the item length is visible once the combo box is closed:

MME: Realtek Line
MME: Realtek Mic
MME: USB Line
MME: USB Mic
DirectSound: Realtek Line
DirectSound: Realtek Mic
DirectSound: USB Line
DirectSound: USB Mic

If we really wanted to restrict visible width when closed you could have Host: Input <device> though I think that is less good.   
 
  
> I think it's not so much a case of wanting to get rid of a prefs pane as 
> it is a case of putting the input channels choice in the user's face... If 
> the user can switch between a mono mic input and a stereo line input in the 
> Device Toolbar, it seems awkward to send them to the Devices Prefs to change > the number of input channels.

+1. Until we made Audacity record in stereo by default we were asked dozens of times a week how you could record in stereo, purely because the choice was hidden in Prefs. This is a golden opportunity to fix this longstanding problem.

I've commited in r10838 the first part of this bugfix which aggregates the device/source selection in the Device Toolbar.
This fixes the input selection on mac ppc (you can now select Core Audio: Built-In Audio: Internal Mic and ...:Line-In instead of just Core Audio: Built-In Audio)
I tested on vista and intel mac 10.6 as well and things seem to be okay there.  However this is a pretty big change that is prone to typos and the main part of this bugfix that will require testing, since the rest is just GUI, so please try it out with some different devices.

Remaining is :
1. add number of channels selection to device toolbar
2. remove device prefs
3. remove source from mixer toolbar
4. add dev toolbar as default (if someone knows where to do this please tell)

Sorry Gale, I just saw your comments, which I think make sense.  I like the heirarchical Host->(Device) structure but keep in mind that there are three elements on some platforms like ppc mac with Host->(Device: Source).  So it would look like:
Core Audio
  RME Fireface
  Soundflower
  Built-in Audio: Line-in
  Built-in Audio: Internal Mic

In this case "Built-in Audio" isn't really useful info, but that's what the device is, and I don't know if we an generalize that it can be removed if there are multiple input sources.  Need more examples I guess.

Still on the fence about the device toolbar, as it looks like there are advantages to both sides.  The GUI stuff can wait until we hash it out and then its decide what goes where - the implementation of that shouldn't be hard.  It  would be nice to have a few more opinions.

(In reply to comment #17)
Thanks, Michael.
> keep in mind that there are three elements on some platforms like ppc mac 
> with Host->(Device: Source).  So it would look like:
> Core Audio
>   RME Fireface
>   Soundflower
>   Built-in Audio: Line-in
>   Built-in Audio: Internal Mic
Isn't Core Audio the (only) host? If so there isn't any real difference. In the Windows comparison, "Windows DirectSound" is host, the "USB Audio" entries are the same as the "external" Fireface and Soundflower, and "Realtek:" (an example of a common motherboard sound device) is the same as "Built-in Audio:"       
Windows DirectSound
  Realtek: Line In
  Realtek: Microphone
  USB Audio Line In
  USB Audio Microphone

Michael, after your commit I get this compilation error building Unicode Release on Ubuntu with standard ./configure &&make:

toolbars/DeviceToolBar.cpp: In function ‘void AddSources(int, int, wxArrayString*, std::vector<DeviceSourceMap, std::allocator<DeviceSourceMap> >*, int)’:
toolbars/DeviceToolBar.cpp:158: error: ‘audacityAudioCallback’ was not declared in this scope
make[1]: *** [toolbars/DeviceToolBar.o] Error 1

Sorry about that.  Please try again with the latest.

Michael: It compiles now on Ubuntu and Win 7 - thanks.

Played with it on Ubuntu but please understand I know little about audio on Linux. All interactions between play and record in Device Toolbar and between Device Toolbar and Devices Prefs seem OK. 

There are many more messages now when launching Audacity from terminal than before. Dozens of instances of:
ALSA lib pcm_dmix.c:1018:(snd_pcm_dmix_open) unable to open slave

Just one of this set:
Expression 'ret' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 1035
Expression 'AlsaOpen( &alsaApi->baseHostApiRep, params, streamDir, &self->pcm )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 1192
Expression 'PaAlsaStreamComponent_Initialize( &self->playback, alsaApi, outParams, StreamDirection_Out, NULL != callback )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 1437
Expression 'PaAlsaStream_Initialize( stream, alsaHostApi, inputParameters, outputParameters, sampleRate, framesPerBuffer, callback, streamFlags, userData )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 2105

and a lot more of this than before:
Expression 'stream->capture.pcm' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 3860

The only consistent problem I found is that if I choose ALSA: hw(0,0) for play and ALSA:pulse for recording AND enable software playthrough then Audacity will freeze every time on record with all the above messages (but those all also occur when recording OK). This may be bug 254 (recording freezes with software playthrough on Linux). When I tested the bug before (not with the above combination of playback and recording device) I did not get the freeze in HEAD but did with 1.3.12 (i.e. PortAudio update since 1.3.12 recovers better from xruns). See this forum thread for details:
http://forum.audacityteam.org/viewtopic.php?f=18&t=14014&start=10#p116831 

but in essence when recording with software playthrough we ignore the user's Audio to buffer choice in Prefs and impose some kind of PortAudio default which on Linux is much more demanding than the default 100ms but in Windows is much less demanding. Autark has written a patch to AudioIO.cpp that forces user's "Audio to buffer" preference to be observed which I had tested on Win7 and Ubuntu and seemed to work but which I have not applied to test your commit. So ATM I don't know if your commit causes the freeze above or if it happened before your patch too. Not going to test more without comments.

(In reply to comment #21)
See Bug 267 for the other messages on launch (the new ones are all additional to those in 267).

(In reply to comment #21)
Gale would you mind applying autark's patch on top of current head and testing?  It looks reasonable, and if it fixes this issue we should probably take it and ask portaudio folks if they like it and it doesn't do anything bad.  I've asked autark on the forum if he wants to do that (since it is his patch and he deserves the credit,) but otherwise we can do it.

I'll look more into what the underlying issue is, but it's going to be rough without a linux box.  Maybe I'll get around to installing linux on my new pc soon.

Also, do you know if any of the linux devices you have have input sources?  I would like to verify that this functionality works.

If you used to get warning messages on play/record, it is probably due to opening new streams to load the device sources.
There should be one new warning message per device/source pair you have, and only on init.
After that you shouldn't be seeing much more.

(In reply to comment #23)
> would you mind applying autark's patch on top of current head and testing?
Yes I can record software playthrough with (hw 0,0) playback and pulse recording device after the autark patch is applied over yours.  

> Also, do you know if any of the linux devices you have have input sources?  
> I would like to verify that this functionality works.
I only have an old box with a theoretical mic and line input on the mobo device but never found a viable Linux driver for it. It works fine on Win98. So I only ever got selection of mic in mixer toolbar (of course not with pulse recording device - mixer toolbar selector then disappears) or alsamixer. Mic does appear as a selectable working choice in Device Toolbar except for the pulse device which just says "ALSA: pulse" (but does record mic). However you want someone who actually has a linux-supported sound device to test if inputs are in Device Toolbar. I would post a question on the Forum to get the widest response. 

> If you used to get warning messages on play/record, it is probably due to
> opening new streams to load the device sources. There should be one new 
> warning message per device/source pair you have, and only on init. After
> that you shouldn't be seeing much more.
No, the expression messages look to be for each pair on init, but there is always one of each expression message when recording with any combo. "ALSA lib pcm_dmix.c:1018:(snd_pcm_dmix_open) unable to open slave" messages appear about 60 times on init and similar number of times on each record with any combo.

Michael, I tried on Win 7 (all OK) and XP (issues as below, Realtek inbuilt device and Trust USB soundcard full mixer device). Realtek inputs are CD Volume and Front Mic (both redundant) and Mic Volume and Line Volume (real inputs). Trust inputs are SPDIF, Line, Mic and Sum.  

In http://www.gaclrecords.org.uk/1.3.12_and_1.3.13_inputs_outputs.png, images to left of the mauve vertical bar are for 1.3.12 on XP; to right of bar for HEAD on XP.

Device Toolbar always initialises empty on XP irespective of the visible devices on quit (tested 10 times now) though it does not interfere with playback or recording. This is not an issue on Win 7.
    
Interactions within Device Toolbar and with Prefs seem OK, and on a cursory test, inputs and outputs behave OK (with proviso that connecting Trust breaks the Audacity input and output sliders for Realtek as per bug 29).

The problems in Device Toolbar are with duplicated mapping devices. 

1) Output: It should be:
 MME: MS SoundMapper - Output
 MME: Realtek HD Audio Output    
 MME: Speakers (USB Audio Output)
 Windows DS: Primary Sound Driver 
 Windows DS: Realtek HD Audio Output 
 Windows DS: Speakers (USB Audio Output)  

Instead, we have four mapped outputs (named as inputs) for MME and four for DS (also named as inputs). Similarly instead of one output device for Realtek and one for Trust for both hosts we have four output devices. All the outputs play whichever you choose.   

2) Input: Again there are four mapped devices for both MME and Windows DS but there should be one each. 

I'm glad devices are now grouped. 

Even with my simple setup there would be 18 entries in the input list once the mapped devices are reduced to two. I can't help thinking the length is intimidating. Have you considered three combo boxes side by side, first one for host (cogwheel or spanner icon, maybe). It should save a bit of width overall as the host will only be written once. 

What would be quite desirable if possible would be for the mapped input/output to display its current mapping. If it was written out it would take more space, but perhaps it could be done by highlighting or arrowing the real input that is being mapped to.

One other point if we use Device Toolbar rather than Mixer Toolbar. I think it needs have a proper docking place. As it is now when you choose an input or output in it the app loses focus.

(In reply to comment #25)
Tested with Audacity 1.3.13-alpha-Jan 6 2011 (Unicode) on G5 dual 2 GHz, and Intel iMac Core 2 Duo.

On PPC 10.5.8:

1) Device toolbar input dropdown correctly aggregates inputs with devices. E.g. shows "Core Audio: Built-in Audio: Line In", "Core Audio: Built-in Audio: Digital In".

2) Mixer toolbar input selector is still displayed for "Built-in" inputs. When "Core Audio: Built-in Audio: Line In" is displayed in Device toolbar input, one can change Mixer toolbar input selector to "Digital In" and the change is not reflected in Device toolbar - the choices displayed in the two toolbars remain out of sync. It appears that the input is actually changed to the digital input based on monitoring the input sound. Furthermore in this case the input slider snaps to zero and can be manipulated (is not greyed out) but always snaps back to zero. If instead one changes Device toolbar input to "Core Audio: Built-in Audio: Digital In" then the input slider is correctly greyed out, and the Mixer toolbar input selector changes to match.

3) Changes made in Prefs > Devices > Recording are not properly reflected in Device toolbar. E.g. if Device toolbar input reads "Core Audio: USB Audio CODEC" and one goes to Devices prefs and changes the Recording device to "Built-in Audio" (note that device and input are not aggregated here), clicks OK, then the Mixer toolbar input selector appears and says "Digital In" or "Line In" depending on the last choice that was made there, but the Device toolbar input choice remains "Core Audio: USB Audio CODEC". It appears from listening to the input sound that the input device has actually been changed from "USB Audio CODEC" to "Line In" or "Digital In". Note that the Device toolbar input choice and the Mixer toolbar input selector are out of sync, and that the Mixer toolbar input selector shows the actual input being used.

4) If monitoring is on, and Device toolbar input says "Core Audio: USB Audio CODEC" (Mixer toolbar input selector is not visible) and one changes the input through the Device toolbar to "Core Audio: Built-in Audio: Line in", the input sound does not change, the meters continue to monitor the USB input, and the Mixer toolbar input selector does not appear. The input is properly changed if you begin recording, or stop then start monitoring, but the Mixer toolbar input selector never appears. In this case the Device toolbar input selector is showing the actual input being used, despite the fact that the Mixer toolbar input selector is not visible.

5) If monitoring is on and Device toolbar input says "Core Audio: Built-in Audio: Line in" and Mixer toolbar says "Line In", and you change Device toolbar input to "Core Audio: Built-in Audio: Digital In" the monitored input does not change and the Mixer toolbar input selector does not update. Stopping then starting monitoring or beginning recording does *not* change the actual input selection - what is displayed in the Mixer toolbar input selector is the input, despite what it says in the Device toolbar.

On Intel iMac 10.4.11

6) Mixer Toolbar Input selector is still displayed for "Built-in" inputs, with its single choice.

7) Because Mixer toolbar input selector has only one choice (when displayed), it cannot get out of sync with the Device toolbar input choice as in case (2) above.

8) If monitoring is on, Device toolbar input says "Core Audio: Built-in Microphone" and Mixer toolbar input selector says "Internal microphone", changing Device toolbar input to "Core Audio: Built-in Input" does *not* change monitored input sound and Mixer toolbar input selector does *not* update. Stopping and starting monitoring, or starting recording, changes the actual input to the line input, but the Mixer toolbar input selector still does not update, so in this case the Device toolbar input is showing the actual input being used, and the Mixer toolbar input selector is lying.

9) Interaction with Devices prefs is OK.

(In reply to comment #26)
Thanks, Bill. I've not considered interactions yet with Mixer Toolbar on XP as I was assuming even if we don't remove Devices Preferences we will remove inputs from Mixer Toolbar. 

I had not checked monitoring, but testing now on Win 7 in a pre-commit build from Dec 16, the problem with changing input in Device Toolbar not changing the currently monitored input (visually or audibly) isn't new. However having made a change in Device Toolbar, just entering Prefs and clicking OK without changing any settings will change the currently monitored input (visually and audibly).

(In reply to comment #25)

> <snip> 
> Even with my simple setup there would be 18 entries in the input list once the
> mapped devices are reduced to two. I can't help thinking the length is
> intimidating. Have you considered three combo boxes side by side, first one for
> host (cogwheel or spanner icon, maybe). It should save a bit of width overall
> as the host will only be written once. 

+1, as "PortAudio requires that all devices specified in a call to Pa_OpenStream() belong to the same Host API." 
(http://www.portaudio.com/docs/v19-doxydocs/api_overview.html)



Also, on my Win 7 machine, some of the entries are truncated at about half the length of other non-truncated entries, and some don't indicate Input/Output (although that may just be what the device reports). Here's the list for output:

MME: Microsoft Sound Mapper - Output
MME: Speakers (Realtek High-Definiti
Windows DirectSound: Primary Sound Driver
Windows DirectSound: Speakers (Realtek High-Definition Audio)

And for input: 

MME: Microsoft Sound Mapper - Input
MME: Microphone (Realtek High-Defini
Windows DirectSound: Primary Sound Capture Driver
Windows DirectSound: Microphone (Realtek High-Definition Audio)

Thanks everyone for testing.

Bill, In the end the input select in the Mixer toolbar, and the preferences will go away, so those particular issues are not going to matter much, but I will take a look at the monitoring issues.  

As per Gale and Vaughan's suggestion.  I will seperate host out to its own combo box and also include "number of input channels" (to reproduce the same functionality in the device prefs).  So I guess the layout is going to be a quad style.

I also noticed the string truncation - I believe this is from portaudio but will double check.

r10852 contains a potential complete for this bug.

I fixed the monitoring issues mentioned by Bill.
I also removed the input source selector from the mixer toolbar as well as the device preferences dialog.  The DeviceToolBar is now on by default, but will require a preferences flush.  We could stick a flag or use the existing version number to turn on the device toolbar once when the new version is ran for the first time on an old prefs file.  Am looking into this.

I tested multiple host (mme, directsound, and asio) on windows and it seems to work.  I could not build audacity with JACK (on the ml there is a post that says the recent portaudio bump does not allow JACK to be included in the build.

Re the string truncation issue, this appears to be a limitation of MME only returning at most 31 characters for the device name due to its old design (Direct Sound will provide the full name.)  I asked the portaudio list for a workaround.

(In reply to comment #30)
> I fixed the monitoring issues mentioned by Bill.
Tested monitoring on Win 7 and XP. Certainly, switching input device in Device Toolbar away from the monitored input stops monitoring it audibly and visually. Should changing the output device stop monitoring the input? It does now.  

XP is same as before:
http://www.gaclrecords.org.uk/1.3.12_and_1.3.13_inputs_outputs.png

i.e. for both MME and DirectSound inputs/outputs you can't map to the Realtek device and there are superfluous mapped devices for the USB card.

Also on XP the Host and Recording channels initialise empty when you restart after initialising prefs, but otherwise the combos initialise OK. Until I initialised prefs the the rec channels combo was corrupted when choosing MME:
http://www.gaclrecords.org.uk/xp_mme_rec_channels_device_toolbar.png

I note Audacity now initialises maximised instead of with a smaller window?

Unfortunately Win 7 now has problems for both MME and DirectSound where it was correct before the last commits: 
http://www.gaclrecords.org.uk/win7_MME_incorrect%20inputs_outputs.png

In the above MME image there is no Realtek Playback device because I've disabled it, however you can see there are superfluous mapped outputs. There are superfluous mapped inputs and also confusing superfluous inputs e.g. "line in: CD audio" (it isn't a driver problem, the other Win 7 computer shows similar behaviour). Here is how it should be:
http://www.gaclrecords.org.uk/win7_correct%20inputs_outputs.png

On Ubuntu 10.10 I only have 800x600 screen and Rec channels is off screen. Even if you tab into the recording channels, no keyboard actions will increment the controls (though you can tab in and use arrow keys on Win). Not sure what you can do about that, though there may be a case for rec channels going in Mixer Toolbar anyway as rec channels does not change the device. Also you would save space if you had an icon instead of text for rec channels. 

Also what about shortcuts for (at least) changing the input device? You removed (of course) the Mixer Toolbar "Adjust input source" shortcut. As it stands now the Device Toolbar is inaccessible on Linux with the keyboard.

>> I fixed the monitoring issues mentioned by Bill.
>Tested monitoring on Win 7 and XP. Certainly, switching input device in Device
>Toolbar away from the monitored input stops monitoring it audibly and visually.
>Should changing the output device stop monitoring the input? It does now.  

I made it match the same functionality as before when changing via the prefs as a starting step, 
I probably would like to see monitoring continue.

>XP is same as before:
>http://www.gaclrecords.org.uk/1.3.12_and_1.3.13_inputs_outputs.png
>
>i.e. for both MME and DirectSound inputs/outputs you can't map to the Realtek
>device and there are superfluous mapped devices for the USB card.
>

There may be a portmixer problem for Devices with input sources.  I take it this problem didn't exist before?  I did some work to eliminate the input sources for output which shouldn't exist.  Unfortunately I don't have xp and can't test.  

I'm not sure about input yet.  On Ubuntu, there are many input sources for me, and while they are suspicious (several devices 'digital', 'analog', and 'spdif' all have the same input sources,) the behavior matches that of pre-fix r10837, when looking at the input sources in the mixertoolbar after selecting each of these devices.  If you are still getting funky input sources please let me know.

>Also on XP the Host and Recording channels initialise empty when you restart
>after initialising prefs, but otherwise the combos initialise OK. Until I
>initialised prefs the the rec channels combo was corrupted when choosing MME:
>http://www.gaclrecords.org.uk/xp_mme_rec_channels_device_toolbar.png

The Rec Channels might be fixed now.

>
>I note Audacity now initialises maximised instead of with a smaller window?
>
>Unfortunately Win 7 now has problems for both MME and DirectSound where it was
>correct before the last commits: 
>http://www.gaclrecords.org.uk/win7_MME_incorrect%20inputs_outputs.png
>
>In the above MME image there is no Realtek Playback device because I've
>disabled it, however you can see there are superfluous mapped outputs. There
>are superfluous mapped inputs and also confusing superfluous inputs e.g. "line
>in: CD audio" (it isn't a driver problem, the other Win 7 computer shows
>similar behaviour). Here is how it should be:
>http://www.gaclrecords.org.uk/win7_correct%20inputs_outputs.png

The screenshots have helped, thanks.  Please send more if there are additional (incorrect) changes.

>
>On Ubuntu 10.10 I only have 800x600 screen and Rec channels is off screen. Even
>if you tab into the recording channels, no keyboard actions will increment the
>controls (though you can tab in and use arrow keys on Win). Not sure what you
>can do about that, though there may be a case for rec channels going in Mixer
>Toolbar anyway as rec channels does not change the device. Also you would save
>space if you had an icon instead of text for rec channels. 

Okay, after we get the device problems fixed I'll add the keyboard control and some way to fit all comboboxes into a narrow window.

>Also what about shortcuts for (at least) changing the input device? You removed
>(of course) the Mixer Toolbar "Adjust input source" shortcut. As it stands now
>the Device Toolbar is inaccessible on Linux with the keyboard.

And these.

(In reply to comment #15)
> Is there a widget you could use in Mixer Toolbar that when clicked, showed/hid the Device choice combo?

s/Device choice combo/Device Toolbar
That's a good idea, lets not lose that in the other discussions.

Otherwise, thanks Michael!  Great work!  This certainly seems to be moving in the right direction!

I have an issue here with the overall Device Toolbar not resizing when it needs to (win 7) resulting in extra/not enough space to the right for the Rec channels: combo, but I'm sure it's fixable (most obvious when toolbar not docked).  I know you are prioritising functionality over layout at this point.

Also, I need a little extra space to the left of 'Rec channels:', it's butting up against the combo box right now.

Thanks for doing all this
Martyn

(In reply to comment #30)
With Audacity 1.3.13-alpha-Jan 14 2011 (Unicode) on Mac PPC 10.5.8 ...

On first launch with a virgin system (no audacity.cfg), the "Rec Channels" dropdown is empty and does not respond to clicks. Making a change in one of the playback or recording device dropdowns populates the Rec Channels dropdown and it then responds to clicks.

The default window is too narrow to display the entire Device toolbar. On my machine the window needs to be 800 px wide.

Making a change to any of the playback, recording or channels dropdowns stops monitoring.

There is a strange interaction with the Transport toolbar Pause button. On my machine, when you click the recording level meters to begin monitoring:
1) If "Built-in Audio: Line In" is selected, the Pause button flashes briefly
2) If "Built-in Audio: Digital In" is selected, the Pause button "lights"
2a) On switching to any other input device, monitoring stops but the Pause button remains lit.
2b) Then if you start monitoring, the Pause button "un-lights".

Michael, if you are testing on Intel Mac then I don't need to, right? The Intel machine I have access to is running 10.4.11.

-- Bill

(In reply to comment #34)
I tested population of dropdowns on Win 7/XP after latest commits but it is complex. The displayed inputs/outputs now seem erratic instead of consistently wrong and I cannot find a pattern to it. They will display differently at different times when nothing has been changed in Audacity Device Toolbar or Windows, or when only switching which device is default/selected input in Windows has been changed. 

In summary, the Win XP outputs are correct but inputs are still consistently showing individual mapped inputs for the USB card on both MME and Direct Sound (here is the MME example):
http://www.gaclrecords.org.uk/XP_inputs_wrong.png

However sometimes the entire contents of inputs and outputs is repeated - so for outputs which are otherwise correct I get for MME:
Microsoft Sound Mapper - Output 
USB Audio
Realtek HD Audio Output
Microsoft Sound Mapper - Output 
USB Audio
Realtek HD Audio Output

Similarly when this happens the 
http://www.gaclrecords.org.uk/XP_inputs_wrong.png  

image is doubled in height and the bottom half is a mirror of the top half. 

On Windows 7 x64 desktop the outputs are usually correct but sometimes show four mapped MME or DS outputs instead of one. The inputs most of the time still show a) superfluous mapped inputs b) conflated inputs like Line In : Microphone  c) devices are now not sorted together:
http://www.gaclrecords.org.uk/win7_DS_incorrect_inputs.png

However once when I started Audacity the above image had the one correct "Primary Sound Capture Driver" but still had conflated inputs and confused device sort. Once it was completely correct (inputs and outputs). Plus sometimes if I change which input is Default in Windows then the entire contents of the inputs and outputs (correct or otherwise) is duplicated (bottom half mirrors top half). 

Removing the USB soundcard seems to improves the likelihood that the Realtek inputs/outputs will be correct (but not by much). 

On the Win 7 i386 netbook, there is similar behaviour but if I don't connect the USB soundcard it is *much* more likely the inputs/outputs will be fully correct when starting Audacity (something like 80% of the time). Once I connect the USB soundcard then about half the time I get the same variety of duplicated mappings/conflated USB inputs/mirrored top and bottom that I see on the desktop. 

After the latest commits on all Win flavours I got flashing in Selection Toolbar (not in Pause) when I changed any of the Device Toolbar combos. A ghost image of Selection Toolbar is drawn above the correct position. This then happened the same way in other pre-HEAD builds (e.g the 1.3.12 public win-unicode release) until I initialised Prefs and restarted HEAD then it stopped happening in all builds. After a while it starts again in HEAD and all other builds so you have to initialise Prefs and restart HEAD (restarting another build is not sufficient) then it stops.   
 
Also I noticed that View > Toolbars > Reset Toolbars removes Device Toolbar even after initialising Prefs and restarting HEAD - I don't think it should do that if Device Toolbar is on by default.

(In reply to comment #32)
>>XP is same as before:
>>http://www.gaclrecords.org.uk/1.3.12_and_1.3.13_inputs_outputs.png
>>
>>i.e. for both MME and DirectSound inputs/outputs you can't map to the 
>> Realtek device and there are superfluous mapped devices for the USB card.
> There may be a portmixer problem for Devices with input sources.  I take it
> this problem didn't exist before?
On XP, before we started fixes, Device Toolbar, Devices Prefs and Mixer Toolbar were completely correct as per left-hand side of:
http://www.gaclrecords.org.uk/1.3.12_and_1.3.13_inputs_outputs.png 

>>Also on XP the Host and Recording channels initialise empty when you restart
>>after initialising prefs, but otherwise the combos initialise OK. Until I
>>initialised prefs the the rec channels combo was corrupted when choosing MME:
>>http://www.gaclrecords.org.uk/xp_mme_rec_channels_device_toolbar.png
> The Rec Channels might be fixed now.
For me on XP, rec channels is now always drawn correctly and populated on restart whether I have initialised Prefs or not - thanks for that.

(In reply to comment #36)

I'll take a look at what's happening on XP, but it will probably be a few days.

(In reply to comment #32)

> 
>> XP is same as before:
>> http://www.gaclrecords.org.uk/1.3.12_and_1.3.13_inputs_outputs.png
>>
>> i.e. for both MME and DirectSound inputs/outputs you can't map to the Realtek
>> device and there are superfluous mapped devices for the USB card.
>>
> 
> There may be a portmixer problem for Devices with input sources.  I take it
> this problem didn't exist before?  I did some work to eliminate the input
> sources for output which shouldn't exist.  Unfortunately I don't have xp and
> can't test.  

All the devices on my XP machine show up fine. But I have a Realtek device on my Win 7 machine, so will check that.


> 
>> Also on XP the Host and Recording channels initialise empty when you restart
>> after initialising prefs, but otherwise the combos initialise OK. Until I
>> initialised prefs the the rec channels combo was corrupted when choosing MME:
>> http://www.gaclrecords.org.uk/xp_mme_rec_channels_device_toolbar.png
> 
> The Rec Channels might be fixed now.

Nope, I confirm what Gale says about restarting after initializing prefs. On my XP machine, the Device Toolbar is shown, but it's an empty and narrow combo box, or maybe several on top of each other, followed by what looks like some detritus from overlapping static texts. I think the problem is in DeviceToolBar::RepositionCombos(), but I haven't found an obvious reason. Looks like they're all x = 0 and minimum width. Don't see why this would be dependent on which version of Windows it is, so if you can't reproduce it on Win 7, let me know and I'll look further.


And now for some nitpicking! :-)

I'm confused by the comments in ToolManager::ReadConfig():
   //we turned the device preferences on by default for the first time
   //as of prefs version 1.1.2r.
   //For users that have older prefs, turn it on once.

...because:
   1) They don't seem to apply to code above or below where they appear.
   2) AUDACITY_PREFS_VERSION_STRING is "1.1.1r1", and "1.1.2r2" appears
      only in that comment. 

Those comments are attributed to Michael. Please fix or remove them.

(In reply to comment #35)
> Also I noticed that View > Toolbars > Reset Toolbars removes Device Toolbar
> even after initialising Prefs and restarting HEAD - I don't think it should
> do that if Device Toolbar is on by default.
Michael, I've looked at your latest commits on Win7 x64, XP  and Ubuntu 10.10.

The above is still a problem i.e. if I float a toolbar, decide I don't like it and Reset Toolbars, I lose the Device Toolbar).    

Since your commits, there seems a hang/excessive CPU problem when making any change in or associated with Device Toolbar (applies to both Win 7 x64 and Ubuntu). The Selection Toolbar corruption has gone though. If I just e.g. change from one input to another there will be superimposed ghost images of Device Toolbar and/or all combo boxes will empty for a few seconds, accompanied by 100% CPU. If I Reset Toolbars then there is a 100% CPU hang for about 15-20 seconds during which there are corrupted ghost images of Device Toolbar and rest of GUI. This is Win7 x64 (visible for 20 seconds):
http://www.gaclrecords.org.uk/win7_reset_toolbars.png

I have rebooted and closed all other apps but makes no difference. 

Unfortunately the problem with duplicated mirrors of the input/output contents seems worse/almost permanent now. Just about any change in Device Toolbar itself will cause it. This is also now evident on Ubuntu where it did not seem to be before. Here is Win 7 x64 outputs after launching Audacity and changing Rec Channels:
http://www.gaclrecords.org.uk/Win7_quadrupled_outputs.png

The input box also has three mirrors, so every input is listed four times with a vertical scrollbar. 

If I change the Rec Channels back, then I have five mirrors for the inputs and outputs so each entry appears 6 times.    

I can't make Ubuntu capture a dropdown image but after making a change there in Device Toolbar, a single mirror appears in outputs and inputs (e.g. 8 outputs become 16). However making further changes doesn't increase the number of mirrors.

The problem with the Rec Channels combo being truncated on initialising Prefs was XP-specific and has gone. However that was when Audacity was initialising maximised and you could otherwise see all of the toolbar. I can confirm that on Windows it seems we initialise to a less than maximised size as before, but as Vaughan says the Device Toolbar is just a stub. Here is Win 7 x64:
http://www.gaclrecords.org.uk/init_prefs.png

Device Toolbar looks the same (it's at the end of Transcription Toolbar) if you then maximise the window: 
http://www.gaclrecords.org.uk/init_prefs_then_maxmise.png  

It isn't possible on Windows to expand Device Toolbar at all without floating it because there is nothing on the right to drag. On Ubuntu 800 x 600, Device Toolbar initialises in its own row but only shows a set of four combo box up and down arrows (no actual box) plus the two icons. It can however be expanded by dragging to right. But even at 800 x 600 it does not need to initialise so contracted as that. 

If we don't want a near full-width Device Toolbar to initialise on its own row, then I would suggest initialising a reduced width Device Toolbar to left of Mixer Toolbar. This is logical and there is room even on 800x600 to do this. Or go the whole way and combine both Toolbars into one. 

The resize itself works quite well and the whole toolbar fits on Ubuntu 800x600 when expanded (should limitless vertical resize when floated be allowed?). However while on Windows you progressively see either "Rec" or "Rec Channels" when you expand, on Ubuntu you progressively see more letters or parts thereof, and they vertically overflow:
http://www.gaclrecords.org.uk/ubuntu_resize1.png
http://www.gaclrecords.org.uk/ubuntu_resize2.png 

My money would still be on not having text for "Rec Channels" and an icon instead. As it is now, some space is indeed saved if you contract the toolbar (the text disappears altogether), but if you expand the toolbar a bit the space that "Rec Channels" takes up seems unwarranted.  I agree an icon choice isn't obvious, but perhaps a mic and a cable with plug?  

Also do we need the "Windows" in "Windows DirectSound" to display? It would be better to see "DirectS" or similar when the Toolbar is contracted than "Window".

(In reply to comment #39)

<snip />
> Since your commits, there seems a hang/excessive CPU problem when making any
> change in or associated with Device Toolbar (applies to both Win 7 x64 and
> Ubuntu). The Selection Toolbar corruption has gone though. If I just e.g.
> change from one input to another there will be superimposed ghost images of
> Device Toolbar and/or all combo boxes will empty for a few seconds, accompanied
> by 100% CPU. If I Reset Toolbars then there is a 100% CPU hang for about 15-20
> seconds during which there are corrupted ghost images of Device Toolbar and
> rest of GUI. This is Win7 x64 (visible for 20 seconds):
> http://www.gaclrecords.org.uk/win7_reset_toolbars.png

I'm not seeing a massive hang, but a brief peak in CPU usage (probably more and for longer than it should).  Selection Toolbar is getting redrawn with a flash of some near-unreadable text (top left).  I could see 'idden' very quickly but when I commented out the only code with that in in SelectionBar.cpp, it just changed to some other garbage.  I only get it when changing the host (Win 7, 'MME' and 'Windows DirectSound' only available).  But in the past my machine has been quicker than Gale's, so that may be the difference there.

<snip />

> Unfortunately the problem with duplicated mirrors of the input/output contents
> seems worse/almost permanent now.

I have never seen this.  I thought it was because I didn't have a USB device so I borrowed an M-Audio transit.  I still don't see it; all the devices appear as they should.  Some sort of race problem?

<snip />
>  I can confirm that on
> Windows it seems we initialise to a less than maximised size as before, but as
> Vaughan says the Device Toolbar is just a stub. Here is Win 7 x64:
> http://www.gaclrecords.org.uk/init_prefs.png
<snip />
> It isn't possible on Windows to expand Device Toolbar at all without floating
> it because there is nothing on the right to drag.

Not quite true, but tricky and unacceptable.  There is a tiny (1 px?) place at the end and top/bottom of the minimal ToolBar where you do get a <-> cursor that can pull it out.

(In reply to comment #39)
<snip />
> Also do we need the "Windows" in "Windows DirectSound" to display? It would be
> better to see "DirectS" or similar when the Toolbar is contracted than
> "Window".

I thinks that's true in this case, but where do we stop?

Presumably we display what is reported by libraries and DLLs/drivers ATM.

Conditionally deleting "Windows ", or other bits that we arbitrarily don't like, is a bit draconian?

(In reply to comment #40)
>> Unfortunately the problem with duplicated mirrors of the input/output contents
>> seems worse/almost permanent now.
> I have never seen this.  I thought it was because I didn't have a USB device 
> so I borrowed an M-Audio transit.  I still don't see it; all the devices appear
> as they should.  Some sort of race problem?
I think it could be. The "mirroring" has got worse on all three of my machines since the new problem with CPU hang appeared. And it's still the case that if I remove the USB sound card, the mirroring occurs less or there are fewer mirrors than when it's connected. I borrowed a Logitech USB headset from someone, and that has pretty much the same effect in making mirroring worse. 

The main Windows desktop where the hang/mirrors is worst has a lot of security related processes running even if I close all other apps. That has always been the case so could account for some of the machine differences.

(In reply to comment #41)
>> Also do we need the "Windows" in "Windows DirectSound" to display? It would be
>> better to see "DirectS" or similar when the Toolbar is contracted than
>> "Window".
> I thinks that's true in this case, but where do we stop?

If "Windows DirectSound" is reported I too have some reservations about stripping out "Windows", but usage of "Windows DirectSound" seems uncommon in practice (4000 hits on Google vs. 4 million for "DirectSound"). 

On:      
http://msdn.microsoft.com/en-us/library/ee419022%28v=vs.85%29.aspx

MS call the API just "DirectSound".

On: 
http://msdn.microsoft.com/en-us/library/ms804961.aspx

they call it "Microsoft DirectSound". 

which is also much more common that "Windows DirectSound". 

Ultimately we don't have "Windows MME" so "Windows DirectSound" seems kind of odd.

(In reply to comment #42)
The latest build I can test is Audacity 1.3.13-alpha-Jan 17 2011 (Unicode) and I don't know if this includes commit R10865 which says "fix sizing and positioning issues.  Also autoresizes now." It should certainly include commmit R10855 "fix num channels redraw - was causing some platforms to display the wxChoice combo box incorrectly"

This is on Mac PPC 10.5.8.

I am seeing the "mirroring" or duplication of devices in the Input and Output popup menus. Undocking then redocking the Device toolbar does not cause it. Making changes to inputs or outputs does not cause it. I cannot change the Host (I have only Core Audio). If I do View > Toolbars > Device Toolbar to hide it, then do that again to show it, I do not see the mirroring.

The only way I can get the mirroring is if I do View > Toolbars > Reset Toolbars (which hides the Device Toolbar) then View > Toolbars > Device Toolbar (which shows it again). I now have two copies of each device in the Input and Output popup menus. If I do that sequence again I have three copies, and so on.

This is with or without an external USB audio device connected. I do have Soundflower installed on my system, and I will try uninstalling it and test again. If that makes a difference I will add another comment.

The following items from my Comment 34 are still there:

The Rec Channels popup menu is still unpopulated and unselectable on launch with no cfg.

The default window size is still too narrow to show the Device Toolbar.

The "strange interactions" with the Pause button still exist.

I tested on Vista/Ubuntu/Mac intel, but not PPC.
I didn't get the unresponsiveness lockup issue, but I bet it is related to the extra sources info.  I'm thinking there is something wrong with portmixer handling extra streams.
I will take a look again on the weekend and make what fixes I can.

>The only way I can get the mirroring is if I do View > Toolbars > Reset
>Toolbars (which hides the Device Toolbar) then View > Toolbars > Device Toolbar
>(which shows it again). I now have two copies of each device in the Input and
>Output popup menus. If I do that sequence again I have three copies, and so on.

Able to recreate this.  I think I fixed it in r10873.  I believe this will fix Bill's issues, but maybe not Gale's as his seems to involve extra input sources from the outset (without menu->reset toolbars)

>The Rec Channels popup menu is still unpopulated and unselectable on launch
>with no cfg.
>
>The default window size is still too narrow to show the Device Toolbar.

Ok, worked on this a bit and it looks better to me now on fresh init.

>I'm confused by the comments in ToolManager::ReadConfig():

Sorry, reverted.  This was something I was going to implement and accidentally committed with other changes.

Tomorrow I will look at the flashing issues.

(In reply to comment #46)
Michael, I updated to r10873 and just tested on win7 x64 (the "slow, secure" desktop, 1024 x 768).   

I initialised Prefs but unfortunately Device Toolbar is still an unrecognisable stub to right of Transcription Toolbar, even if I maximise after launch. Here is a close-up(1):
http://www.gaclrecords.org.uk/Win7_Device_Toolbar_230111_init_prefs.png 

I cannot expand the stub by hovering because no draggable triangle will show. I can only make the triangle appear by grabbing the drag bar on the left(2):
http://www.gaclrecords.org.uk/Win7_Device_Toolbar_230111_drag_while_docked.png

That does not help me expand the toolbar, so I Reset Toolbars. After the 20 second CPU hang, I do still see Device Toolbar but only the same stub exactly as in (1). So the only way I can use Device Toolbar is to float it. After dragging it over the background I see a draggable triangle without combos just as when I drag when docked. If I don't expand it and Reset Toolbars, it goes back to a stub next to Transcription Toolbar. If I float and grab the triangle, instead of letting me resize a bit, it jumps to 610 px width which I cannot contract further. If I then Reset Toolbars it docks into its own row at a smaller 520 px width(3):      
http://www.gaclrecords.org.uk/Win7_Device_Toolbar_230111_after_float_and_reset.png

So my comments:

1) Generally, the width after reset from an expanded, floated Toolbar seems to depend on the width when I reset, which I find disconcerting (Meter Toolbar resets to the same width). If the project window is maximised and I reset Device Toolbar from a width of 750 px, it docks at 630 px width; from 700 px it docks at 590 px.   

2) At 520 px (image 3) the DirectSound host shows "Windows". I like that less every time I see it - are the devices really reporting "Windows Direct Sound"? 

3) The new 610 px min width when floated is too wide, yet has wasted space (before "Rec" and after the rec channels combo)(4):
http://www.gaclrecords.org.uk/Device_Toolbar_min_floated.png

4) I strongly think initialising Device Toolbar to right of Transcription Toolbar is a bad idea - there isn't sufficient space there to be useful. There looks to be reasonable unused space alongside Mixer Toolbar for a "minimal width" Device Toolbar. If you made Meter Toolbar initialise to single height (often asked for - the meter bars don't need to be that high vertically) you could then initialise Device Toolbar alongside Meter Toolbar which gives more width for Device Toolbar. Even with double height Meter Toolbar as now, you could put another toolbar underneath Device Toolbar if it was docked alongside. 

Generally there is a lot of wasted toolbars space in an initialised window - we could go further and make Tools Toolbar morph to a single-height row of 6 tools so it can dock alongside more toolbars. I have looked carefully at 800x600 on Ubuntu and I think any of the above suggestions are feasible even at that resolution. 

If we don't want to start adjusting other toolbars to use space better then I think Device Toolbar has to initialise on its own row as it does if you float and expand it, then Reset.   

As for the mirroring, Reset Toolbars rarely caused it for me and still doesn't. After your commits, I had to use the Device Toolbar controls a lot to get mirroring in outputs, so that is an improvement. However input mirroring occurs as soon as I make any changes in Device Toolbar controls or change the Default Device in Windows (again, not so often if I don't have a USB device connected, but still at least half the time).

Ok I tested the initial width problem.  Was not an issue for mac or linux, but Windows had a problem with ToolBar.cpp's ordering of sizer calls.  Should be fixed in r10874

Re the "Windows DirectSound" it is what portaudio calls the host, not something Audacity or Windows creates.
line 1091 of pa_win_ds.c:
    (*hostApi)->info.name = "Windows DirectSound";

We can patch or change within audacity code if desired.

selection issue fixed in r10875.

The issue comes from selection toolbar and was related to updating project preferences.  I commited a workaround so that this behavior is not exhibited from DeviceToolBar interaction, not a complete fix.  The flashing still happens for example if you go to preferences and click ok.

(In reply to comment #48)
> Re the "Windows DirectSound" it is what portaudio calls the host, not 
> something Audacity or Windows creates.
> line 1091 of pa_win_ds.c:
>(*hostApi)->info.name = "Windows DirectSound";
Thanks. I'd still be +1 on "DirectSound". It would probably let us get down to 500px min width for the toolbar and "Windows DirectSound" does not appear to be a phrase that MS uses. 

The current initialised Device Toolbar width seems fine in terms of display. Good to see it always reset to the same width now. I'd still like it to contract to a smaller min width by dragging (as we could a few commits ago). It would give more options for fitting alongside other toolbars. 

I note with the current re-arrangements the Meter Toolbar initialises to about 155 px width against the circa 270 px in 1.3.12. I'm sure it's hard juggling with the widths and how it affects initialised and maximised views but I doubt 155 px is acceptable. People already complain about the Beta Meter Toolbar width compared to 1.2. Can you try 200 px please? On Win 7 1024 x 768 (pretty modest these days) the 200 px lets me keep an identical layout to 155 px when window is initialised and maximised. Possibly if we were to reduce the initialised width of Device Toolbar further, we might have a bit more flexibility with where the toolbars initialised?  

----

After initialising Prefs. on Win 7 I see a blue widget to right of the Host combo every time I change to Windows DirectSound:(1)
http://www.gaclrecords.org.uk/win7_init_prefs_DS_host.png

It disappears as soon as I click somewhere else. If I then maximise and expand the Device Toolbar until at least the "Rec" word shows, then contract it as far as I can, there is a space between the input device combo and rec channels combo that wasn't there in (1).     

On Ubuntu 800x600 I still have the issue that the "Rec Channels" text overflows as soon as you expand enough to show it(2):  
http://www.gaclrecords.org.uk/Ubuntu_maximised.png

(but unlike Win, the space for "Rec Channels" disappears when I contract again).   

----
Testing on Ubuntu since your last commits the CPU hang when resetting toolbars does seem better. The delay is only about 5 seconds now and Ubuntu doesn't grey the screen out as before. This is what it looks like:(3)
http://www.gaclrecords.org.uk/Ubuntu_reset_toolbars.png:

But still really long and bad hangup on Win7 x64:(4)
http://www.gaclrecords.org.uk/win7_reset_toolbars.png  

----

There is one issue that may have started fairly soon after we started making changes, but I had not figured the cause until now. On all three machines (so Ubuntu, Win7 i386, Win7 x64), USB device connected or not, the output slider resets to max when I restart Audacity after intialising prefs. It also resets (whatever the current host or device) when I open and close any combo in Device Toolbar, even if I don't change the setting.
 
----

Mirroring issues unchanged.

(In reply to comment #38)
>>> XP is same as before:
>>> http://www.gaclrecords.org.uk/1.3.12_and_1.3.13_inputs_outputs.png
>>>
>>> i.e. for both MME and DirectSound inputs/outputs you can't map to the Realtek
>>> device and there are superfluous mapped devices for the USB card.
>>>
>>
>> There may be a portmixer problem for Devices with input sources.  I take it
>> this problem didn't exist before?  I did some work to eliminate the input
>> sources for output which shouldn't exist.  Unfortunately I don't have xp and
>> can't test.  
> 
> All the devices on my XP machine show up fine. But I have a Realtek device on
> my Win 7 machine, so will check that.

This may be old for testing, i.e., Michael may have already fixed the problem Gale was seeing, but fwiw, the Realtek device shows up fine on my Win 7 machine, with latest from SVN.

(In reply to comment #50)

> 
> After initialising Prefs. on Win 7 I see a blue widget to right of the Host
> combo every time I change to Windows DirectSound:(1)
> http://www.gaclrecords.org.uk/win7_init_prefs_DS_host.png

I don't get that on my Win 7 machine with initialized prefs. But when started from initialized prefs, the number-of-channels menu is flush against the Input Device menu and the right boundary of the toolbar. Should have a little space on each side, imo.

When the width of the Device Toolbar is small, "Rec Channels:" disappears, when it's an intermediate size, it shows just "Rec". Both of those are fine, but when it's "Rec", the 'c' is right up against the number-of-channels menu. And when it's "Rec Channels:", the 'R' is very close to the Input Device menu.


> <snip>
> ----
> Testing on Ubuntu since your last commits the CPU hang when resetting toolbars
> does seem better. The delay is only about 5 seconds now and Ubuntu doesn't grey
> the screen out as before. This is what it looks like:(3)
> http://www.gaclrecords.org.uk/Ubuntu_reset_toolbars.png:
> 
> But still really long and bad hangup on Win7 x64:(4)
> http://www.gaclrecords.org.uk/win7_reset_toolbars.png  

I see that on both XP and Win7 x 64, but it doesn't stay that way. And the menu disappears before it starts drawing, so I never see it like that image.

Looks like it's drawing the Device toolbar in successively lower places in the window, then refreshes the whole upper toolbar area and all are drawn correctly. Too many calls to DeviceToolBar::OnPaint() while they're all being positioned?

(In reply to comment #46)
With Audacity 1.3.13-alpha-Jan 24 2011 PPC Mac 10.5.8

* Rec Channels popup menu is still unpopulated and unselectable on launch with no cfg. Making any selection (not necessarily a change) in any of the other popup menus populates the Rec Channels popup menu.

I launched Audacity with no cfg and immediately quit. I then made a copy of the cfg file. Then launched Audacity again with the "default" cfg. Rec Channels still unpopulated. Made a selection from the output device menu (thus populating the Rec Channels popup) and quit. Then compared the two cfg files.

The "default" version had this:
[AudioIO]
Duplex=0
NoModifyDevice=1
PlaybackDevice=Built-in Audio
Playthrough=0
RecordChannels=2
RecordingDevice=Built-in Audio
SWPlaythrough=0

The "working" version (where the Rec Channels menu was populated) had this:
[AudioIO]
Duplex=0
NoModifyDevice=1
PlaybackDevice=Built-in Audio
Playthrough=0
RecordChannels=2
RecordingDevice=Built-in Audio
SWPlaythrough=0
Host=Core Audio
RecordingSourceIndex=0
RecordingSource=Line In


Default window width appears to be 600 px, but Device Toolbar appears to be 520 px. Why not make it 600 px? Minimum Device Toolbar width to properly display everything ("Rec Channels", and non-truncated Host, input and output devices) is 760 px on my system. How long are we going to continue to support monitors with less than 1024 px width?

Possibly OT, but why is the Transcription Toolbar on by default?

* Input level slider does not disable (as it should) when I select "Built-in Audio: Digital In" or "USB Audio CODEC". It reverts to the old (incorrect) behaviour of being selectable but snapping back to full volume. The old fix of opening and OKing the Devices prefs is no longer available.

* Default toolbar positions puts the Edit Toolbar between the Mixer and Device Toolbars. It makes more sense to me to have Mixer and Device Toolbars one above the other.

* Re Gale's comment about the Meter Toolbar, it looks to me like it could default to 255 px and still fit in the 600 px window.

* I no longer get device mirroring/duplication.

-- Bill

(In reply to comment #53)
Do we need any text for "Rec Channels"? It seems to cause a fair number of minor issues. I think ideally it should have an icon, but we don't have icon or text for Host which is less understandable than input channels. In any case, sighted users will see a tooltip for all combos which should reduce misunderstanding. 

Another idea: could you draw a box around the input device and input channels to make clearer they belong to each other? When we have multichannel playback I assume we will have an output channels box, which is one reason I'd prefer to see the Device Toolbar initialised-width less than it is now. Yes it could initialise to the full 600px, but if it was say 460 px Transcription Toolbar could go alongside it even when window is 600 px. That would save an entire toolbar row at 600px width. I do think Transcription Toolbar has to be on by default - too many people use it to do otherwise.    

I am not sure Mixer and Device Toolbar one above the other would work well in practice unless they are integrated into one toolbar with the combos as a slideout or dropdown which don't appear until you click a widget. The only way it would look good otherwise IMO would be to align the speaker and mic icons of each toolbar underneath each other and that leaves a lot of hard to fill space either side of Mixer Toolbar. 

As for 800x600, I have Ubuntu dual booting with Win7 i386 on a modern netbook and can't get higher than 800x600 under Ubuntu with any video driver I can find.  

> Input level slider does not disable (as it should) when I select "Built-in
> Audio: Digital In" or "USB Audio CODEC". It reverts to the old (incorrect)
> behaviour of being selectable but snapping back to full volume.
Yes confirmed on both Win 7 and Ubuntu with a first generation Ion USB turntable which I only keep as a backup. Also I notice both Mixer Toolbar sliders have lost their hover tooltips "Input Level Slider" , "Output Level Slider".  

I'll try XP again presently for device content.

(In reply to comment #54)
If the minimum screen size we're supporting is 800x600, can we initialize the window to 780x500 or 800x500 or something similar? The 780 px width allows a reasonable Device toolbar (not too truncated) beside the Transcription toolbar.

(In reply to comment #55)
> can we initialize the window to 780x500 or 800x500 or something similar?
Seems a reasonable idea. Even on 1024 x 768 there would still be useful space to right if the screen initialised a bit wider. 

I agree a downside of reducing the intialised Device Toolbar width below what it is now would be to make the entries less intelligible. But once a user is familiar with the entries, do they need to see the entire width when the Toolbar is not in active use (given the screen estate that uses)? As an alternative to the combo box text not being visible at all until clicked on, could the dropdowns be of reduced width when closed, then when clicked on, expand to their maximum width i.e. as in Track Drop-Down Menu?

Tried latest code on win XP 32-bit. Outputs display/work fine. Here are the inputs when the USB sound card is set as default in "Sounds and Audio Devices" in the Win control panel (MME host): 
http://www.gaclrecords.org.uk/WinXP_inputs_USB_Trust_win_default.png

There are still the duplicated mapped inputs (they actually select the inputs they suggest). I sometimes get mirroring of the whole input list if I change the recording channels but it doesn't reliably happen. Changing inputs or outputs or host does not create any mirrors. If I reset toolbars the mirrors are removed on this machine but on Win 7x64 the reset will usually add to the mirrors or leave the existing ones there. Changing host doesn't change behaviour.  

I had not tried this before but here is what happens on Win XP if I change the Win default to Realtek motherboard sound and restart Audacity (MME host):
http://www.gaclrecords.org.uk/WinXP_inputs_Realtek_win_default.png

There is only one mapped input but it records low level noise, seemingly whatever input I choose in Win control panel. There is no <input> choice for the device, just a device choice either of which records low level noise. I changed which input is checked as Realtek default in the Win control panel and restarted Audacity but it did not change anything. Then I removed the USB sound card and restarted Audacity. The only change is the removal of "USB Audio" from the input and output list, and as before no choice records any useful input. No mirroring of the input list occurs when Realtek is Win default. Changing host doesn't change behaviour. So on XP I can't record in 1.3.13 while Realtek is Win default. On Win 7 x64, choosing which device is default and restarting does not change the input list except that it sometimes produces a mirror.    

Tried 1.3.12 on Win XP. Choosing mapped input in Device Toolbar (which happens to be Realtek mic) works. Choosing Realtek HD Audio input in Device Toolbar works (I can record from the chosen input in Mixer Toolbar: 
http://www.gaclrecords.org.uk/WinXP_1.3.12_inputs_Realtek_win_default.png

>I note with the current re-arrangements the Meter Toolbar initialises to about
>155 px width against the circa 270 px in 1.3.12. I'm sure it's hard juggling
>with the widths and how it affects initialised and maximised views but I doubt
>155 px is acceptable. People already complain about the Beta Meter Toolbar
>width compared to 1.2. Can you try 200 px please? On Win 7 1024 x 768 (pretty
>modest these days) the 200 px lets me keep an identical layout to 155 px when
>window is initialised and maximised. Possibly if we were to reduce the
>initialised width of Device Toolbar further, we might have a bit more
>flexibility with where the toolbars initialised?  

It is currently at 160 px at least as far as the wx layout is concerned.  I tried 200 and down to 170px.  On Ubuntu, which seems to be the most width greedy because of the different (ciruclar) transport buttons, this causes the meter toolbar to bump down to the next row.  So a cross platform solution will be a bit trickier than this.
We can think of something smarter than the current rearrangement system which includes the initial project widths based on screen size etc, but I suggest this be it's own thread as I expect there will be much discussion.

Several issues are addressed as of r10886:
-Let device toolbar be shrunk smaller than the initial 500px (mentioned by Gale)
-fixed a case where Initial (no audacity.cfg) number of input channel combo box wasn't populated (mentioned by Bill, but could not replicate on ppc 10.4 - probably because of the way my system orders the inputs)
-Add dialogs and shortcuts for each combo box (shift + i/o/a/n) (mentioned by Gale, Leland, and Richard)
-Removed 'Rec Channels' static text label and appended 'Input Channel(s)' to the combo box because this effectively works with any size (mentioned by Gale)
-Made the device toolbar height half-size on linux (tested on ubuntu 10.10) to match mac and win

(In reply to comment #58)
>> I note with the current re-arrangements the Meter Toolbar initialises to 
>> about 155 px width against the circa 270 px in 1.3.12... I doubt 155 px is 
>> acceptable. People already complain about the Beta Meter Toolbar width 
>> compared to 1.2. Can you try 200 px please?
> It is currently at 160 px at least as far as the wx layout is concerned. 
> I tried 200 and down to 170px.  On Ubuntu, which seems to be the most width
> greedy because of the different (ciruclar) transport buttons, this causes the
> meter toolbar to bump down to the next row.  So a cross platform solution
> will be a bit trickier than this. We can think of something smarter than 
> the current rearrangement system which includes the initial project widths 
> based on screen size etc, but I suggest this be it's own thread as I expect
> there will be much discussion.
Michael, I largely agree "smarter decisions about initial layout" is really an enhancement, as single-height Tools and Meter Toolbar are, but I really doubt I can "sell" 160 px for Meter Toolbar. E.g. four of the six comments on the Win Nightly Build since this change have remarked on it. 

I don't know what resolution you tested at on Ubuntu but on 800 x 600, about 180 px width definitely would make Meter Toolbar overflow. But that is on the current initialised width of 600 px. I think we can get extra width for Meter Toolbar by initialising to a greater width, as Bill pointed out. There is almost nothing useful you can put to right of initialised Audacity on 800x600 so from that perspective the initialised width could easily be 650 px or whatever without being a problem on larger resolutions. I assume if we initialised to say 650 px then we could initialise Meter Toolbar to about 230 px which is much more reasonable. I would even say go for 700 px or more to give a better display for Device Toolbar. Can you consider this please? For many people on large resolution monitors I think an expanded initialised width would be a good move anyway.       

PS On Gnome/Ubuntu the Transport Buttons look the same as on Win to my uneducated eye.

It won't compile on Linux for me at r10887, did last night at r10882:

toolbars/DeviceToolBar.cpp: In member function ‘void DeviceToolBar::ShowComboDialog(wxChoice*, const wxString&)’:
toolbars/DeviceToolBar.cpp:867: error: ‘class wxChoice’ has no member named ‘ProcessCommand’

Richard

Created attachment 69 [details]
debug patch that might fix mirroring issues

Gale, can you please test this patch to see if it fixes your device mirror problems.

I am just taking a farshot guess that there's a bug in portmixer that makes it act up sometimes when more than one mixer exists.

Hi Michael

Try setting a breakpoint in DeviceToolBar::Layout() and then do
View -> Toolbars -> Reset Toolbars

Without the breakpoint I'm seeing multiple DeviceToolBar's flash up, then a delay before it all resolves.  With it I see dozens of hits on that breakpoint.

Lots of calls due to OnResetToolBars and then lots due to AudacityProject::HandleResize here (Win 7 debug).  Like the first lot stack up events that are then handled by the second lot.  But I'm no expert at event handling.

I still think there may be a race condition due to all these calls to the same thing, resulting in those mirrored things, but I've no firm evidence.

Surely we don't need dozens of calls to DeviceToolBar::Layout()?  Some reorganisation required?

TTFN
Martyn

(In reply to comment #59)
> fixed a case where Initial (no audacity.cfg) number of input channel combo box
> wasn't populated (mentioned by Bill, but could not replicate on ppc 10.4 -
> probably because of the way my system orders the inputs)

With Audacity 1.3.13-alpha-Jan 31 2011, OS X 10.5.8 PPC, input channel combo box is now populated on launch with no audacity.cfg.

The "strange interactions with the Transport toolbar Pause button" from Comment 34 remain, but are probably not new and not directly related to this bug.

(In reply to comment #62)
> Created an attachment (id=69) [details]
> debug patch that might fix mirroring issues
> 
> Gale, can you please test this patch to see if it fixes your device mirror
> problems.
Michael, I tried your patch. On XP, situation is "no change" so still as per comment 57. On Win 7 i386 and x64 with USB devices connected or not, there is now no mirroring in outputs even after resetting toolbars or changing devices in Audacity or Windows. On Win7 i386 and x64 with no USB devices connected, there is now no mirroring of inputs even after resetting toolbars/changing devices, but when USB devices are connected there is input mirroring and conflation for both USB and motherboard device. Here it is after connecting a USB device and restarting Audacity on initialised .cfg:
http://www.gaclrecords.org.uk/win7_DS_incorrect_inputs.png

On Win7 x64 it is still fairly easy to add further mirrors by changing one of the Device Toolbar combos or making changes in Windows, but it definitely doesn't happen mechanistically as it did before your patch. On Win7 i386 it is as before more difficult to get mirroring but it still happens occasionally (maybe 1 time in 10 a mirror will appear as opposed to 1 time in 5 before).  

I like your shortcuts and dialogues for Device Toolbar (but I think we want a colon after the text label for the controls). Mixer Toolbar hover tips and input slider disabling works OX for me now on Win and Ubuntu. 

There is a minor glitch when contracting Device Toolbar - the right-hand drag bar gets behind the input channels combo box, so it it very difficult to expand it without merely opening the combo instead):
http://www.gaclrecords.org.uk/win7_minimal_width_device_toolbar.png

A bit more about the reset of the output slider to max when changing Device Toolbar combos or initialising prefs (comment 50) - when this happens Audacity no longer controls the hardware and in fact the slider no longer has any effect at all. The only way to get control back after launching on initialised .cfg or changing a combo is to restart on a populated .cfg.

(In reply to comment #65)

Gale, so if I understand your comment means XP is still problematic and looks like this?
http://www.gaclrecords.org.uk/WinXP_inputs_USB_Trust_win_default.png

This image doesn't look like a mirror to me.
The "Microsoft Sound Mapper" is just a virtual device that resolves to a physical default device (in your case USB Audio.)  So Microsoft Sound Mapper and "USB Audio" should in fact have the same sources.
And the Realtek sources are completely different strings.
But maybe I'm misunderstanding something.

Your win7 with usb input stuff seems very strange.  I will give it another look, and try to get a usb device to try (to this date I only tried firewire devices)

(In reply to comment #66)
> Gale, so if I understand your comment means XP is still problematic and looks
> like this?
> http://www.gaclrecords.org.uk/WinXP_inputs_USB_Trust_win_default.png
> This image doesn't look like a mirror to me. The "Microsoft Sound Mapper" is 
> just a virtual device that resolves to a physical default device (in your case
> USB Audio.)  So Microsoft Sound Mapper and "USB Audio" should in fact have the
> same sources...
Michael, 

Yes we should map to an input source of the USB device when that device is Windows default device, but "Microsoft Sound Mapper - Input" (MME) or "Primary Sound Capture Driver" (DirectSound) can only map to *one* input source at a time (i.e. whatever is the current Windows default such as "Realtek line-in" or "USB Sum"). That's the whole point, so if you preferred you could change the default input in Windows and then leave Audacity permanently on the single mapped input choice. Horrid image, but this is what it should look like on any Windows platform with a motherboard device and a single USB device attached: 
http://www.gaclrecords.org.uk/winXP_correct_inputs.png

On Win 7 i386 that is exactly what it looks like for much of the time until the occasional mirroring starts (so that I get "Microsoft Sound Mapper - Input" and all the other lines listed x times). Note that on XP when I make the motherboard device the Windows default I do get only "Microsoft Sound Mapper - Input" but the problem is then that:
a) "Microsoft Sound Mapper - Input" does not record anything 
b) The other entries are only devices with no input source, so similarly record nothing. This is what it looks like with Realtek set as default Windows device: 
http://www.gaclrecords.org.uk/WinXP_inputs_Realtek_win_default.png   

Remember that on XP and earlier Windows is not presenting the inputs as separate devices - if you have a Realtek mobo device and USB card there are only two devices. Please see these images:
http://wiki.audacityteam.org/wiki/Mixer_Toolbar_Issues#xpcp

Mixer Toolbar broke on Win Vista/7 precisely because those versions of Windows started presenting each input as a separate device.

A fix is in to not trace the input sources for the mapper device.  Am I correct in that this is just an issue for windows ds and mme?
There was no clean way through the portaudio API so the solution is a bit of a hack that relies on the mapper always being the first device listed for a given audio host.  I believe this to be true; let me know if it isn't.

I tried using a USB audio input device on my vista, but it was one without sources, so maybe that's why I couldn't replicate anything.

Also regarding the mirroring issue on win7 can you post one of your nice pictures?
I am going to try to install win7 soon if it will help.

(In reply to comment #68)
> A fix is in to not trace the input sources for the mapper device. 
> Am I correct in that this is just an issue for windows ds and mme?
As far as I know there are no mapped devices in a normal Mac setup. On Linux, I'm a bit vague because I can only get a single mic input with any drivers I can find ATM... but isn't the "default" choice a mapping?   

> I tried using a USB audio input device on my vista, but it was one without
> sources, so maybe that's why I couldn't replicate anything.
I was also getting the mirroring even with a borrowed Logitech USB headset without sources, but here it is before the last commits, with the USB sound card connected:
http://www.gaclrecords.org.uk/win7_DS_incorrect_inputs.png

I've now tested HEAD but *without* your debug patch of a few days ago. Not sure if that's what you wanted. 

There are a lot of improvements on Win 7 (both x64 and i386). There is only one (proper) mapped input now, I can't make "mirroring" happen at all, and the output slider reset has stopped happening. I can't find any problem when there is no USB device connected. When a USB device is connected, it still all works well from a functional POV (e.g. if I change the default device in Windows from a Realtek input to a USB input or vice versa, the mapped choice in Audacity respects the new default). The only issue seems to be that connecting a USB device produces a list where the Realtek and USB inputs are not sorted together:
http://www.gaclrecords.org.uk/win7_DS_correct_but_unsorted_inputs.png

XP has not improved so much. As on 7, there is now only one (proper) mapped input, the output slider reset has stopped happening, and there is no mirroring. However when the Realtek motherboard device is default Windows device (whether a USB device is connected or not), the explicit input choices are still only a device choice with no inputs, and none of the input choices will record:
http://www.gaclrecords.org.uk/WinXP_inputs_Realtek_win_default.png

When an external device is connected it works better. (I'm ignoring Bug 29 for the moment - that is still an issue here but not on Win 7 as far as I can tell). I can change in Windows to another input belonging to the device that is current Windows default device, and the Audacity mapped choice will record from it. However if I change the Windows default devices to another device (in the XP sense, e.g. from a current Realtek input and output to a USB input and output) then the Audacity mapped input and output will be silent until restart. In 1.2.6 and 1.3.12 the mapped input would still work in that scenario.

----

I now get a full right-hand drag bar for Device Toolbar when reducing it to minimum width, but there are glitches again when changing host. On XP and Win 7 changing from from DirectSound to MME always corrupts the area to right of the output combo until you click somewhere else. Here it is on XP with a dragged out Device Toolbar:
http://www.gaclrecords.org.uk/XP_DS_to_MME.png  

and on Win 7 with Device Toolbar at default width:
http://www.gaclrecords.org.uk/Win7_DS_to_MME.png

View > Reset Toolbars is much quicker now even on Win 7 x64 (that is slowest, showing this:
http://www.gaclrecords.org.uk/win7_better_reset_toolbars.png
 
or similar for about 4 or 5 seconds instead of 15 - 20 seconds. Other machines show that sort of image for a couple of seconds or "subliminally".

>> A fix is in to not trace the input sources for the mapper device. 
>> Am I correct in that this is just an issue for windows ds and mme?
>As far as I know there are no mapped devices in a normal Mac setup. On Linux,
>I'm a bit vague because I can only get a single mic input with any drivers I
>can find ATM... but isn't the "default" choice a mapping?   

Do you mean the portaudio reported default device?  This doesn't create problems for the current system.  just portaudio devices that are mappers will require our special case handling.

>I've now tested HEAD but *without* your debug patch of a few days ago. Not sure
>if that's what you wanted. 
>
>There are a lot of improvements on Win 7 (both x64 and i386). There is only one
>(proper) mapped input now, I can't make "mirroring" happen at all, and the
>output slider reset has stopped happening. I can't find any problem when there
>is no USB device connected. When a USB device is connected, it still all works
>well from a functional POV (e.g. if I change the default device in Windows from
>a Realtek input to a USB input or vice versa, the mapped choice in Audacity
>respects the new default). The only issue seems to be that connecting a USB
>device produces a list where the Realtek and USB inputs are not sorted
>together:
>http://www.gaclrecords.org.uk/win7_DS_correct_but_unsorted_inputs.png

Ok, well that's good.  Let's hope it stays that way.
Portaudio is returning the list out of order, probably because windows is.  Can you compare how the devices look in other programs or the system panel?  We could try to sort, but it will be tricky because of the string truncation issue for mme.


>XP has not improved so much. As on 7, there is now only one (proper) mapped
>input, the output slider reset has stopped happening, and there is no
>mirroring. However when the Realtek motherboard device is default Windows
>device (whether a USB device is connected or not), the explicit input choices
>are still only a device choice with no inputs, and none of the input choices
>will record:
>http://www.gaclrecords.org.uk/WinXP_inputs_Realtek_win_default.png

I didn't find the reason for this but will take another look.

Also I can replicate your display glitches and will address them.

(In reply to comment #70)
>> ...isn't the "default" choice a mapping?   
> Do you mean the portaudio reported default device?  This doesn't create
> problems for the current system.  just portaudio devices that are mappers 
> will require our special case handling.
I meant, isn't the "default" choice in the output and input combo of Device toolbar a mapper device? 

The glitch changing host from DS to MME isn't solved on Win7 x64, only on the Win7 i386. Here it is after initialising prefs, maximising the window then changing to DS and back:
http://www.gaclrecords.org.uk/win7x64_ds_to_mme_after_init_prefs_then_max.png

Perhaps you just need to force a refresh for sluggish machines?

I'm afraid I don't have good news. All those improvements for Win 7 and partial improvements for XP were in HEAD ANSI release (I still build that on VS 2005 as I'm trying to retain Win 98/ME support through to 2.0 to give those users a final, high quality Audacity version). In a complete fresh HEAD checkout and building Unicode Release on VS2008, I'm back to all the old behaviour exactly as per comment 65 for both Win 7 flavours and XP, except that I now only have one mapped input. So e.g Win 7 x64 or i386 has the output slider resets and (for the USB sound card) the conflated explicit input devices. Either the Logitech USB headset or the USB sound card add mirrors when you click in a Device Toolbar combo (though that happens much less often on i386). Here is how it initialises on either Win 7 machine in Unicode Release with the USB sound card connected:
http://www.gaclrecords.org.uk/win7_any_arch_init_inputs.png

The USB sound card has I believe correct drivers for each platform i.e. different for each of Win7 i386, Win 7 x64, Win XP (i386) and Win 98, and works as expected in 1.3.12. The Logitech headset only has Microsoft drivers as that is all that are available. I'll see if I can get some more QA input here from people on Windows. 

If it's any clue... if I run 1.3.13 ANSI Release then run 1.3.13 Unicode Release, then I get the much improved ANSI behaviour (as per comment 69) in Unicode Release. As soon as I run Unicode on an initialised cfg, I get the crazy behaviour mentioned above. This is completely reproducible even after restarting the computer. I guess someone else could build Unicode Release and post a copy for me to test, though I doubt it will make any difference.

As regards input device order in Device Toolbar (on ANSI Release!) the order isn't what Windows shows. Here is the Windows order compared to the Device Toolbar order:
http://www.gaclrecords.org.uk/win7_input_order.png

However, Goldwave and Cool Edit Pro show the same order as Device Toolbar. Here is Goldwave:
http://www.gaclrecords.org.uk/goldwave_rec_devices.png

I'll leave you to make a value judgement about sorting by device, but if a user has several devices, a device sort *really* does help.

In my last builds of ANSI and Unicode Release I got the following warning in Visual Studio:  

DeviceToolBar.cpp
..\..\..\src\toolbars\DeviceToolBar.cpp(815) : warning C4101: 'outputSelectionIndex' : unreferenced local variable

I think this started after the r10911/10912 pair of commits.

(In reply to comment #72)

Fixed (removed).

(In reply to comment #65)
GA wrote:
> I like your shortcuts and dialogues for Device Toolbar (but I think we want a
> colon after the text label for the controls). 
Also I documented these new shortcuts yesterday and it struck me it might be less confusing if they were in the order that you see them in the app. i.e. 
- Change audio host
- Change output device
- Change input device
- Change input channels

Gale, can you verify that you've cleaned the solution and rebuilt?  It's probably not causing issues for you but I bring it up just in case.
I spent a couple hours debugging a slider bug to see that my portmixer settings were affected by this since I recently installed directx sdk we use custom build events to configure this (which can't be tracked by the standard build command in msvc.)

(In reply to comment #75)
> Gale, can you verify that you've cleaned the solution and rebuilt?
Whenever I do a "Nightly" I always delete the build folder and delete \win\Projects\Audacity\Unicode Release (or Release) then clean the solution. But as it says above, to test my observations in Comment 71 I did a complete fresh checkout into a new tree.

Understood (I saw the comment but wasn't sure (since the build isn't in svn.)

I'm still clueless as to what's the issue so, can you try this while I try to install xp?
http://michaelchinen.com/mike/misc/mc_win_UnicodeRelease_11022011.zip

(In reply to comment #77)
> I'm still clueless as to what's the issue so, can you try this while I try to
> install xp?
> http://michaelchinen.com/mike/misc/mc_win_UnicodeRelease_11022011.zip

Thanks, Michael. I only tested on Win 7 to date, every time on initialised .cfg. If on Win 7 x64 I run my HEAD Unicode Release or yours from its respective build folder (after adding the five wx* dll's), they both give the Device Toolbar behaviour as in my HEAD ANSI Release, run without libs present and as available at:
http://www.gaclrecords.org.uk/audacity-win-1.3.13-alpha.zip 

If I run your Audacity Unicode Release executable from the folder I release from (which is thus minus all the libs, but has the wx* and ms* dlls and the Microsoft.VC90.CRT.manifest version 9.0.21022.8), it initialises the same as my Unicode Release i.e. the conflated inputs:
http://www.gaclrecords.org.uk/win7_any_arch_init_inputs.png

If I put your executable in the folder I run HEAD Unicode Release from on Win 7 i386, I see the same conflated inputs (but also as expected, a much reduced tendency to create mirrors). The i386 is not a build machine, but the x64 is. 

Are you building on an x64 architecture, and should it make any difference to anything?

>Are you building on an x64 architecture, and should it make any difference to
>anything?

Yes, I was, but I would hope it shouldn't matter since we're only targetting 32 bit.

I got my xp partition up and building. the good news is I can replicate (I think all of) your xp issues which seem related to bug 29.  I didn't have issues with just a USB and motherboard sound (with all mapper combinations,) but when I added a firewire device to the mix problems came up.  The bad news is I haven't figured it out yet.

(In reply to comment #79)
> I got my xp partition up and building. the good news is I can replicate 
> (I think all of) your xp issues which seem related to bug 29
I think so. If on XP I uninstall the mobo device and run ANSI Release, then (most of the time) I can initialise to get inputs for the USB sound card. It isn't quite consistent. After a few repeats it will just show the mapper and "USB Audio" and then reboot is needed to get the inputs back. Unicode Release shows no inputs under any combination of installed devices, even if run with libs in the folder.

I think the fixes today should address xp and what happens when you change the default device before starting up audacity.  please check.
There are still problems when changing the default while audacity is running.  This appears to be due to a portaudio bug.  I have contacted them; not sure if it can be easily resolved.
I commited a workaround for this case - rescanning devices (under transport menu).  If the default devices are changed while audacity is running the user can use this command to restore a working device list.
Coincidentally this allows users to rescan to get new or trim disconnected devices.

(in reply to comment #81)
Thanks very much, Michael. I'm yet to test fully, that will take a while, and I'll try to get others to test too with their devices. 

Transport > Rescan Audio Devices can then also be marked as a workaround for bug 41. However I noticed there is almost no overhead on the rescan (barely a flicker in the Device Toolbar combo boxes). Would it be practical to force a rescan every time user pressed Play, Record or Pause? That could theoretically fix bug 41 and this problem. We could revert it if and when PortAudio fixes it. If not, I wonder if a button on Device Toolabr with a Refresh icon would be better - it won't be easy to figure where the rescan is if it is in a menu.      

Incidentally with the current HEAD (even Unicode Release on Win 7 x64), View > Toolbars > Reset Toolbars is now near instantaneous.

-1 for button on device toolbar.  
+1 for rescanning on play/record/pause.

This is looking like it's coming to a resolution!

Attach the rescanning to some other event, so that a user who plugs something in and waits for it to appear, sees it appear?  But without providing major extra load?

-1 for scanning on some other event.
They'll have to select the new device anyway, and it will rescan then.

(Also changed to SUMMARY bug as per comment by Gale in Bug:113)

(In reply to comment #85)
> -1 for scanning on some other event.They'll have to select the new device 
> anyway, and it will rescan then.
Martyn has a point, the newly plugged-in device won't be in the menu until the rescan is done. If we can also rescan when user selects a Device Toolbar combo, that should do it.

We can try to do the rescan on idle if the user doesn't have monitoring on.  Since this is a device related issue would have to test performance on many systems so I think its best to consider that an enhancement to be done after the bug is closed.

Adding it to play/rec (via AudioIO::StartStream) is probably ok if the performance isn't an issue, so I'll try this first.

If it is possible please let me know before the weekend if this is still broken on win7 so I know if I need to install it.

(In reply to comment #88)
Michael, briefly - no change for me on Win 7 x64 or i386 after the changes for the singleton Device Manager. Still get conflated inputs with Unicode Release (unless I run it from its build folder). ANSI Release does not have that issue even if run from outside its build folder. 

I think XP is pretty good now after your changes (Unicode or ANSI), but I'm still getting info. from other testers. I'll comment before the weekend about that. 

I'm a bit hesitant about "rescan on idle" for lower power machines and the testing it might need. Being able to rescan on selecting the combo would be better IMO if it can be done (plus on Play/Rec).

I installed windows 7 to test.  Could not replicate your conflated input problems on Release, Unicode Release, and Unicode Debug.  I tried all device permutations as well as switching the default and clicking the combo boxes a lot.
Is there some possible setting that I am overlooking that would trigger this issue?
I also downloaded your nightly and could not replicate it, so presumably it is not a build issue.
What ratio of other win 7 testers have this problem?  can we narrow a cause down?

(In reply to comment #90)
Numbers are small, but of the four Win 7 people I'm trying to communicate with ATM, three see the issue. 

One has the same Trust USB Soundcard as I have.

One has a Snowball USB mic (that single input is listed OK, but the SoundMax inputs are conflated and mirror easily).

One has a Behringer UCA 202 (same comment as Snowball, the mobo (Realtek) inputs are messed up).

The one that is OK has a Logitech USB headset. He has seen an occasional mirror but otherwise OK. 

Usually (but not infallibly) removing the USB device removes the conflation from the mobo device. If you reboot without the USB device connected the mobo device is then OK (I've only tested that once). 

Ed Musgrove on Win 7 x64 had (I think) the same conflation issues as me until you did your singleton device manager. He now seems to get correct mobo inputs but has a lot of issues such that he has never been able to record properly in Audacity 1.3. I think those issues are just with his FW device but I am not sure. I am going to send you his stuff-off list and let you see what you think. 


Thanks

Thanks for the info.
I discovered I can replicate this under XP (SP3) compatibility mode.  Are you running this as normal, or under the mode?  Are we supporting/recommending these modes?

(In reply to comment #92)
Do you meant the XP Mode Virtual Machine:
http://www.microsoft.com/windows/windows-7/features/windows-xp-mode.aspx

or as I assume right-click over audacity.exe > Properties? 

I'm not doing either and at least two of my current correspondents aren't, but I'll ask the others. 

I ran the ANSI in right-click compatibility mode for XP SP2, XP SP3 and Vista  without conflated inputs, but 2000 mode gives conflated inputs (this is pre your latest commit). I can understand this happening, but not why the Unicode behaviour is different or more device-dependent.  

Someone told me in HEAD of a few months ago that XP Mode (VM) worked "well" and Audacity could select input sources in Mixer Toolbar. Someone else told me that it was no better than setting compatibility mode by right-click (inputs appeared in Mixer Toolbar, but did not allow recording). My line would be we're aiming for Audacity to be Win 7 and Vista compatible so in almost all cases it should work without right-click compatibility mode (and VMs are not recommended). Compatibility mode would be last resort, but we should check a virgin install on 7 (and Vista) is still installing OK without compatibility mode.

Yes, I meant the compatibility mode via properties.  I'm still digging into this.
On my machine the conflated behavior for running win 7 audacity under XP mode appears deterministic and logical (although wrong) - portaudio is getting the windows 7 device sources as devices, and portmixer is getting the device sources (as xp would) and attaching it to these.  I'm not seeing any of the change/addition of new sources on clicking a combo box.  do you see this still?

Also, regarding attaching rescan to play/pause etc, on my win7 the scan takes a few seconds, so I would say we shouldn't attach it there.
Debugging says that the enumeration for direct sound devices is what is slowing it down.

(In reply to comment #94)
> On my machine the conflated behavior for running win 7 audacity under XP mode
> appears deterministic and logical (although wrong) - portaudio is getting the
> windows 7 device sources as devices, and portmixer is getting the device
> sources (as xp would) and attaching it to these. 
I agree it sounds very logical but I'm assuming there are device interactions too - the guy with the Snowball gets the ANSI release to cause conflation if run in any compatibility mode, but I only get it with Win 2000 mode. None of those four are running in compatibility mode, but three are getting conflation with the Unicode Release (and one with the ANSI release too). And clearly it's the presence of the USB devices that cause the conflation to all devices, so it's something like the behaviour in bug 29 (which seems better on XP now).

> I'm not seeing any of the change/addition of new sources on clicking a combo 
> box. do you see this still? 
Yes on the x64 machine unless I either run ANSI or Unicode from its build folder.  

> Also, regarding attaching rescan to play/pause etc, on my win7 the scan takes
> a few seconds, so I would say we shouldn't attach it there. Debugging says 
> that the enumeration for direct sound devices is what is slowing it down.
Shame, but I guess not surprising. I just think that the menu item to rescan will necessarily be hard to discover. Is there any chance that it's slow because it's a debug build? If you have a patch I'd be happy to try it on my win7 x64 which should be a good test of a lethargic machine.

I sat and stepped through portaudio/portmixer code for a whole day and couldn't find the cause.

I did find that my conflation issue is not a regression as the same behavior exists in 1.3.12 under win7 xp compatibility mode (although you need to reselect an appropriate output device for the inputs to show up since it doesn't contain my portmixer fix).  So my compatibility issues are probably not yours.  But just in case can you please check that this is not the case for you?

Also, can you post a before and after screenshot of the combobox changes before and after you click?  The change may be helpful for identifying the bug.  I don't think you posted one, but correct me if I'm wrong.

Lastly, as I search for a workaround, are there any win7 cases where we have genuine input sources as opposed to win presenting sources as devices?  If not then maybe it is time to hack it to just not search for sources.

(In reply to comment #96)
> I did find that my conflation issue is not a regression as the same behavior
> exists in 1.3.12 under win7 xp compatibility mode...  But just in case can 
> you please check that this is not the case for you?
In 1.3.12 on Win 7 x64 or i386, switching to any XP compatibility mode does not create conflation, or affect the content of input or output combo in any way. Same for the current correspondents. All compatibility does for me is create a non-functional mixer toolbar input selector.       

> Also, can you post a before and after screenshot of the combobox changes 
> before and after you click?  The change may be helpful for identifying the 
> bug.  
Here is how Unicode Release (if run standalone without build libs) initialises on clean .cfg on win7 x64:
http://www.gaclrecords.org.uk/Win7x64_input_conflation.png

The only input that I can record from is the mapper - the weird choices all record from the mapper. 

Since your singleton device manager, the "mirroring" (when you get conflation) doesn't seem to be simply a repeat of the entire combo contents. Instead, random parts are mirrored, while some of the conflated input groups may disappear, while other inputs may "fix themselves" and then work even if they are not the mapped device. For example see the working "Microphone (USB Audio)" here which happened after five open and close actions in the input combo: 
http://www.gaclrecords.org.uk/win7x64_after_combo_clicking.png

BTW the three Win 7 people above who have the conflation are all on x64. The one who has only "occasional mirroring" (of correct input contents) is on i386. That seems replicable for me on i386 too. The "occasional mirroring" is the "old" variety that we first saw - the entire combo contents is duplicated (the duplicates all work correctly I think). But you have to click around far more than you would in normal use to make it happen.  

> As I search for a workaround, are there any win7 cases where we have
> genuine input sources as opposed to win presenting sources as devices? 
> If not then maybe it is time to hack it to just not search for sources.
As per comment 91, if a non-mixer USB device is connected (on x64), the single input "USB Audio Codec" is listed once correctly and works, but its presence comflates the mobo mixer inputs. That's true e.g. if I connect a USB turntable on x64.

Michael, on Win7 x64 I checked Goldwave running in XP compatibility mode (SP2 and SP3) and in the Vista and 2000 compatibility modes. Inputs are always displayed correctly and work correctly <source device> (<input device>) just as they do with no compatibility. Though that would I guess be our ideal too, I'm not sure if our not being able to do that yet is the cause of the problem. What does the fact that the problems go away when the libs are included tell you?

found and fixed a bug in r10956 that would only reveal itself on some systems.  Please retest.

(In reply to comment #99)
Unfortunately, nothing much has changed for me or the guy with the Snowball Mic on Win 7 x64 (conflated input devices from initialised .cfg, unpredictable mirroring after clicking). Not heard from the other two on Win 7 x64. Heard from someone else on Vista x64 with an Art Pro RIAA USB pre-amp who sounds as if he has the same issues, also from someone with a Grace USB turntable on Win 7 x64 who does *not* see the issue. (These are all reportedly on latest Unicode nightly).       

On the plus side, I did not get any mirroring on Win 7 i386 this time even with aggressive clicking around.

r10907 has a portmixer fix for some wrong code that would have affected vista/win7.  It may affect the input/mirroring bugs.  Can you please check to see if this fixes an issue?
Note that you don't need to collect test results from everyone before posting - if the issue exists for you we can say it still exists and I need to look more for the fix.

(In reply to comment #101)
> r10907 has a portmixer fix for some wrong code that would have affected
> vista/win7. 
I'll test for r10970 which I think is what you mean. 

Are the occurrences on x64 as opposed to i386 irrelevant - i.e. when I finally lose this problem should I be more aware of i386 people on various devices to make sure they're OK too?

Ok thanks!

>Are the occurrences on x64 as opposed to i386 irrelevant - i.e. when I finally
>lose this problem should I be more aware of i386 people on various devices to
>make sure they're OK too?

After the bug is fixed in x64 we should make sure it is also fixed in i386, since the behavior seems different.

Updated but sadly there are still problems. On Win 7 x64 when I first intialised .cfg and launched Unicode Release it all looked perfect but I pressed Record and got silence so it wasn't picking up the mapped line-in input of the USB sound card. Then when I clicked again in the input combo the list changed exactly to the mirrored/conflated list I'd seen before:
http://www.gaclrecords.org.uk/win7x64_after_combo_clicking.png (1)

That meant USB line-in (mapped) and USB mic (explicitly picked) worked. After that I couldn't get any further changes in the list by clicking, whereas before 10970 I could get further parts of the bottom of that list mirrored if I clicked around enough times. 

Rebooted, initialised .cfg and launched Audacity and this time it initialised to the completely conflated list that it always used to:
http://www.gaclrecords.org.uk/Win7x64_input_conflation.png (2)

With this list only the mapped input device works. Lots of clicking later, I finally got to (1) again. Rebooted, initialised .cfg and launched Audacity three more times, and I got (2) to begin with twice and (1) to begin with once. So it's unpredictable and in some ways worse now.

ANSI Release (built on VS2005) on Win 7 x64 still seems to give the correct list and records the intended device, as Unicode Release does if I run it from its build folder. Unicode Release run without the libs as we would release it seems to list and work correctly at the moment on Win 7 i386 and I did not get any mirroring.   

Have not pushed latest Unicode Release build to anyone else yet.

Gale, I've looked more into the bug's dependency on your dll/directory settings, and now again think it may have something with compatibility mode.  More info can be found in threads like this:
http://www.ms-news.net/f3603/bug-in-sp4-getversionex-2099373.html
So it seems like it is more than just going to properties and setting compatibility mode as windows can flag applications automatically as needing compatibility.  I don't know the details but I guess this happens on crashes.  I found some threads that say the application name and directory are logged.
This would explain why only certain systems would be affected, and only why changing the name or directory affects things.

In Vista and Win 7 portmixer is hardcoded to never return input sources using the audio endpoint API, since they are all returned as aggregated devices.  So I am guessing that somehow your audacity was flagged by windows as needing to be run in compatibility mode.
I've checked in microsoft's recommend way of finding version which supposedly will work around it.  This method uses VerifyVersionInfo() instead of GetVersionEx().  This fixes the issue for me when I run under compatibility mode.  Please check to see if this changes the behavior on your computer.

Even if this fixes the bug he compatibility settings issue (if true) may present slowdowns.  Unfortunately it does not seem so simple (at least involving registry editing) to undo these compatibility settings once flagged.

(In reply to comment #105)
Michael, thanks for your research. I'm rebuilding now, but before doing that I force quit Unicode Release in its build folder three times, then rebooted. It still lists devices OK. Repeated the exercise and it still lists OK. But we don't know how exactly Windows flags this, if this is the real problem. 

When I run Unicode Release after recompile from a folder without libs, I'll name the directory as something that's never been used before. 

And if true, how does Windows present this "forced compatibility" to the user? Is the Properties sheet checkbox to toggle compatibility greyed out?

(In reply to comment #106)
> When I run Unicode Release after recompile from a folder without libs, I'll
> name the directory as something that's never been used before. 
I did that using the build before your latest fix and I got the usual conflation. 

Using the build including your latest fix but run from its usual folder, things are still not right. On an initialised .cfg the combo lists "look" OK to begin with and the mapped device works, but when I actually change to another input, it will fairly soon revert to exactly this again:
http://www.gaclrecords.org.uk/win7x64_after_combo_clicking.png (1)

"Fairly soon" means it's unpredictable but within 5 to 10 changes.  

Until it reverts to (1), the explicit choices for the mobo device record, but those for the USB sound card do not. After it reverts to (1), the only choices that work are the mapped device and "Microphone (USB Audio)". Any amount of clicking/changing does not change away from the list in (1).

Choice of Host does not seem to affect behaviour. 

I made one discovery but I have no idea what it means. If I use the shortcuts and keyboard to change the selected input devices, the list remains correct as initialised however many changes I make. This does not make the explicit USB inputs record. I have tried using my "mousemu" mouse emulator and a real (optical) mouse to click but both seem liable to revert the list to (1).  

If I initialise .cfg and launch Audacity without the USB card present but with the Logitech headset connected, listing is OK and does not change when changing devices, but choosing the explicit "USB Audio Codec" for the headset records silence. The headset will record if it is the mapped device. Clicking to change devices does not change the list or the behaviour.    

If I initialise .cfg and launch Audacity without the USB card or USB headset present, listing and selection is OK. 
 
Using the build including your latest fix run from a folder name "E:\Z888989898" that I have never used before makes no difference to any of the above behaviour. Explicitly choosing different compatibility modes does not affect behaviour. They are all consistent in initialising to a correct unconflated list but then behaving as above. 

I'm kind of getting the impression 10970 might not have helped Win 7 USB devices to actually record (as opposed to list correctly). Could there be another typo to be fixed or a matching change needed? I notice on Win 7 i386 that the explicit choices for the USB sound card now only record silence, so that's gone backwards somewhere. The explicit choice for the headset (USB Audio Codec) works fine on Win 7 i386. There are no listing problems. I did use XP a bit yesterday after 10970 and AFAIK all is still OK there.  

Obviously, no user results yet. Should I update to Win 7 SP1? Neither Win 7 machine has it though they are up-to-date with Windows updates and the SP1 isn't much more than already issued updates AFAIK.

Ok, thanks for the report, I'll look more into it.
I think you should stay on whatever operating systems you are on as they exhibit the bug.
One question - when it initializes 'correctly' is this without input sources?  The expected behavior for win7/vista that there are only aggregated sources as devices.  You should not be seeing any sources after colons in vista/win7 as you do in your after corruption image.

(In reply to comment #108)
> One question - when it initializes 'correctly' is this without input sources? 
> The expected behavior for win7/vista that there are only aggregated sources 
> as devices.  You should not be seeing any sources after colons in vista/win7
> as you do in your after corruption image.
Yes the correct list that it initialises to has only proper aggregated devices. I have now gone to "Sound", disabled the mobo line input and restarted Audacity, to see if the combo box handles that OK. It does, here is what I see:  
http://www.gaclrecords.org.uk/win7_x64_01Mar11_init.png 

So just to recap  - if I press Record with that set up, without changing devices in the combo, then the mapped device and "Microphone (High Definition Aud)" record, but the Line (USB Audio) and Mic (USB Audio) do not. I can't test the SPDIF (USB Audio), and the mobo "CD audio" is one of those "pointless" devices that isn't even connected to the CD drive.  

ANSI release and Unicode Release (run with its libs) are listing correctly without unwanted changes. But they also won't now allow recording on Win 7 x64 with the USB card or headset, unless it is mapped. Those builds won't allow recording on Win 7 i386 with the USB card unless it is mapped, but allow it with the USB headset.

Three reports against HEAD (no compatibility mode):

* Win 7 x64 Sound Blaster X-Fi Surround 5.1 - report seems to be identical to my experience with the Trust Sound Card. OK with 1.3.12.     

* Win Vista x64 Ion USB Turntable - all OK including able to record from explicit USB Audio Codec, but conflated listing appeared once after clicking rec channels. Then only mapper recorded until Audacity restarted, then all OK as before.   

* Win 7 x64 Snowball USB mic (that previously exhibited conflated SoundMax
inputs when Snowball connected)  - listed correctly but only mapper recorded, until rebooted and intialised.cfg. After that no problems with listing and recording from explicit device.

Rebooting doesn't help me and this could still I guess merely indicate erratic behaviour?

Gale, I made only one relevant fix since your last comment.  This was a memory leak fix and I would be surprised if it actually fixes the issues for this bug.

I'll look into this again today, but if no active devs can replicate the bug is it possible to get vnc access to a tester's machine that can build audacity?

(In reply to comment #111)
> I'll look into this again today, but if no active devs can replicate the bug is
> it possible to get vnc access to a tester's machine that can build audacity?
None of the people that have recently been testing this and finding issues are not AFAIK able to build. There is someone I could ask who I figure would be willing, but I don't know if he has the subject problems. Of course I could help, have I to build Unicode Debug?   

I haven't really been pushing this around much in the last few days, but the gist of what I have seen is that most of the problems are with mixer devices. Most (but not all) with just a USB mic or headset can it seems record from the explicit USB Audio Codec without it being mapped. Win 7 x64 Snowball USB mic guy is still OK having seen problems then rebooted. 

Also I built ANSI Release at r10969 and then it could record from the explicit USB choices again, not just when the USB device is mapped. So 10970 still seems to be relevant somehow.  

And that thing about keyboard shortcuts not corrupting the listings seems a fluke. It was consistent at the time but after a reboot, the shortcuts can corrupt the listings just like mouse clicks.

(In reply to comment #112)
>> I'll look into this again today, but if no active devs can replicate the bug is
>> it possible to get vnc access to a tester's machine that can build audacity?
>None of the people that have recently been testing this and finding issues are
>not AFAIK able to build. There is someone I could ask who I figure would be
>willing, but I don't know if he has the subject problems. Of course I could
>help, have I to build Unicode Debug?   

If you can help that would be great.  I realize it's a lot to ask both in terms of trust and time to handover control of a computer.
If you think you can do it please mail me off list and we'll verify/setup a time to setup VNC and do the actual work.
I believe Unicode Debug isn't necessary as I can just set Unicode Release to build debug symbols.


>Also I built ANSI Release at r10969 and then it could record from the explicit
>USB choices again, not just when the USB device is mapped. So 10970 still seems
>to be relevant somehow.  

I will take a look at this.

Michael, as a generalisation your memory fix (unexpectedly?) seems to have reduced the frequency of many people's Vista/7 conflation problems, and some devices seem to be recording again with the explicit device choices even with the current code, but none of this seems to be 100% reliable. Occasional unpredictable conflation will occur, and occasionally you must map the input device to make it record. 

One guy reported something new on Vista 32-bit SP1 when a USB headset is connected and a mobo explicit choice is selected - press Record and the mobo choice will change to something else and silence will be recorded. But Transport > Rescan moves the choice back where it was and then it records. 

Snowball guy apparently went back to getting conflated Sound Max devices after combo clicking (when Snowball was connected), after which only mapped device recorded. Once again,a reboot fixed it. But other people find when they can't record from the explicit choices, the list still displays correctly.
  
Sound Blaster X-Fi Surround 5.1 user does not seem to have seen any improvement at all. He's the only one I'm following where the memory fix did nothing.     

Adding to the complication, Windows has today updated my USB sound card drivers on Win 7 x64 while apparently removing the older drivers. The device is now called "C-Media CM106 Like Sound Device" instead of "USB Audio". First impressions are that the "new" device is working OK with the Realtex mobo device, but then "USB audio" was doing so much of the time after the memory fix. To get the older drivers back I would have to uninstall (putting me back to MS drivers) then reinstall the older drivers. Do you want me to do this? 

All very frustrating when you don't really know for sure whether/how long it's going to work for, yet you can't repro the problem when you want to see it. I guess though most people who record once from a specific device then exit Audacity might not see a problem much of the time.

Interesting that the driver update fixes it.  Don't know what that means yet.

 if it is possible can you compile a small list of the cheaper devices that still fail?
Details such as model number would be appreciated.
I'm thinking to pick a cheap one up to test.

Michael, OK here is a short list:

Sound Blaster X-Fi Surround 5.1
http://us.store.creative.com/Sound-Blaster-XFi-Surround-5.1/M/B0017QQQAE.htm

Art Pro RIAA USB USB Phono Plus v2 
http://www.artproaudio.com/products.asp?cat=9&type=86&id=128

Behringer UCA 202
http://www.behringer.com/EN/Products/UCA202.aspx

Trust SoundCube USB Sound Card
http://www.trust.com/products/product.aspx?artnr=17002
(I do *not* have this model, but it has been recently reported as being very erratic (often records silence and "sometimes" conflates the Simatel mobo inputs on Win 7 x64). No problem in 1.3.12. 

Trust 5.1 External Surround Sound Card
http://www.trust.com/products/product.aspx?artnr=14134
(I *do* have this model and at the moment I and the other person mentioned somewhere up above are "largely" OK. Other person is on Vista 32-bit and has not received a driver update. "Largely" means we have both seen conflation on the motherboard inputs when Trust is connected once since my last post. I got silence recording from an explicit input once (without any listing corruption) but rescan fixed it. Other person has seen this issue twice).  

Logitech H530
http://www.logitech.com/en-gb/webcam-communications/internet-headsets-phones/devices/7115 

currently seems to behave like Trust 5.1 but slightly more likely to exhibit conflation or silent recording. 

I have not had or seen reports of "mirroring" for some time now. 

If you choose a device I think you will be more likely to repro the issues  with a "sound card" or interface. 

If you can run to two devices, you could try Snowball mic: 
http://www.bluemic.com/snowball/

as that "might" eventually repro consistently after a while (reboot to fix it).

Note that the motherboard device could be an influence too. I know some people who have the devices in this comment who have been completely OK from about half way through our fixes, but they have a different mobo device than people who still have issues when they connect the USB device. 

Are you still sure 10970 was correct or complete? The impression I still have is that 10970 made things worse in terms of being able to record from explicit sources (the SoundBlaster guy is still better off pre-10970) but the memory fix somehow seems to have helped or possibly covered up any issues in 10970.      
  
* If you particularly want to speak to any of the above people I could give them your address, though I think asking any of them to build is out of the question.        

* You can still VM into my machine but I'm not sure how long it would take to see the problems. You might have a higher chance with the older drivers for the Trust card. Basically I'm fairly happy with "Like Sound" on Win 7 x64 HEAD but I couldn't rely on it e.g. for a Timer Record unless I had mapped the device first.

Ok, since it looks like the Behringer is the cheapest available soundcard I will try to pick one up.  I can't seem to find the problematic trust card in germany.

In my area it looks like they have a lot of similar models (UCA222, U-Phono UFO202) but not the UCA202, so I may have to order/ebay one.  But if you have had a report on those let me know.

Re 10970, I looked over the changes and it seems like it really is correct (as it is a one-line typo.)  It is possible that the change triggers some bad behavior that is actually caused by the real bug.  I will keep it in mind as I look at the surrounding code, though.

(In reply to comment #117)
> In my area it looks like they have a lot of similar models 
> (UCA222, U-Phono UFO202) but not the UCA202, so I may have to order/ebay one.
AFAICT the UCA222 is identical with the UCA202 except for extra bundled software, so go with the UCA222.

I got a hold of a behringer uca 202 and couldn't get any bad behavior after several hours on win 7 on unicode release and debug.  I also tried a previous nightly that should have had problems.
Perhaps it is related to some other system thing?  I messed around with the properties in the sound control panel, but couldn't get anything to trigger that bad behavior.  If you have some ideas please let me know.

(In reply to comment #119)
> If you have some ideas please let me know.
Different motherboard device, as already indicated. We know some people are OK and some aren't with the same external device; and AFAICT there aren't issues when that USB device is absent. I guess this is essentially the same problem as bug 29.   

System differences too. I would try looking at memory and how stressed the system is. I found out that the SoundBlaster guy had audio cache on so I suggested he turned it off. He hasn't seen conflation since then (though it's too early to tell for sure) and is getting far fewer silenced recordings from the explicit input choices. Note I do not have audio cache on. Do you want an image next time I see the conflation? Though that is not a predictor of when the mapped device won't record. 

Meantime could we please have a sufficient initialised width of the Meter Toolbar, which is now almost unusable for serious work as a result of the changes made in this bug? Looks like a P2 regression to me.

> System differences too. I would try looking at memory and how stressed the
> system is. I found out that the SoundBlaster guy had audio cache on so I
> suggested he turned it off. He hasn't seen conflation since then (though it's
> too early to tell for sure) and is getting far fewer silenced recordings from
> the explicit input choices. Note I do not have audio cache on. Do you want an
> image next time I see the conflation? Though that is not a predictor of when
> the mapped device won't record. 

I don't expect system load to cause these types of errors, but if you notice that these problems arise only under heavy use conditions please let me know.
I couldn't find out what the 'audio cache' is or how to set it by looking around the sound control panel or googling.
The image will be helpful if it has changed from the last one.

> Meantime could we please have a sufficient initialised width of the Meter
> Toolbar, which is now almost unusable for serious work as a result of the
> changes made in this bug? Looks like a P2 regression to me.

Ok, I changed it to 255px as suggested above.  In the above discussions I said that above 160 doesn't look good on linux because the transport toolbar appears larger (in scale and px) on my machine, but I guess you have to decide.  As far as I know I haven't made any changes to the init width of the meter toolbar (the 160 was in before I started working on this bug.)  If you have more issues please do open a new bug and tell me the desired width (by setting and looking in your .cfg to get the value).  This way we won't have this device related thread intermixed with a GUI discussion.

(In reply to comment #121)
> I couldn't find out what the 'audio cache' is
It's our memory cache:
http://manual.audacityteam.org/man/Directories_Preferences#cache

Turning it off significantly reduces the problems for that SoundBlaster owner. 

I've turned audio cache on now in both Win 7 x64 and i386 to try and provoke issues to happen more often.  


> The image will be helpful if it has changed from the last one.
It has not changed apart from the name change in the USB device due to driver update, and apart from the fact that the inputs are no longer duplicated. The conflation is only in Realtek. 

Microphone (High Definition Audio): Microphone 
Microphone (High Definition Audio): Line-in   
Microphone (High Definition Audio): Stereo Mix
Microphone (High Definition Audio): CD Audio

 
> Ok, I changed it to 255px as suggested above.  In the above discussions I said
> that above 160 doesn't look good on linux because the transport toolbar 
> appears larger (in scale and px) on my machine, but I guess you have to 
> decide.  As far as I know I haven't made any changes to the init width of the
> meter toolbar (the 160 was in before I started working on this bug.)  
Thanks, will take a look. The problem people saw was that on fresh .cfg the Meter Toolbar starts out much less wide than before. This did change during the course of the Device Toolbar changes. 


> If you have more issues please do open a new bug and tell me the desired 
> width (by setting and looking in your .cfg to get the value).  This way we 
> won't have this device related thread intermixed with a GUI discussion.
Fair enough, now we've agreed we need the Meter Toolbar wider. 

Thanks for your efforts with the device issues. On numbers I have to hand, it looks like ~30% of people on 7/Vista who are regular USB device users receive the current issues at some time or another.

> > I couldn't find out what the 'audio cache' is
> It's our memory cache:
> http://manual.audacityteam.org/man/Directories_Preferences#cache
> 
> Turning it off significantly reduces the problems for that SoundBlaster owner. 
> 
> I've turned audio cache on now in both Win 7 x64 and i386 to try and provoke
> issues to happen more often.  

I turned it on and wasn't able to see any bad behavior.  So maybe this is a motherboard issue.

I committed a few code cleanups and extra checks which should prevent modification of the maps between device rescans, which should be the only way that the contents of the combo boxes could change like the way you are getting them to.

Dev note: What really is strange to me is that when the conflation happens it seems to be using the wave API (non-win 7 and vista) portmixer.  The only way I can see that happening is with some kind of memory stomping, since it initializes clearly using the endpoint API (win 7 and vista.)  Even stranger is that for new combos to appear from the wave API it means a device scan is happening between combo cilcks.  Memory stomping can do all sorts of stuff, but this seems a little to deterministic to just focus on DeviceManager and portmixer, so I'm still not sure.

In any case,  can you please try the new commits and see if the conflation still happens?  It may have some effect, but I don't expect it to, so it should be lower priority for you.

I've seen the conflation twice on Win 7 x64 since I wrote last, but that was before your commits. Both occasions were after turning audio cache on, but that may not mean anything. I used Win 7 i386 again for a bit and had no issues (uses same Trust sound card but 32-bit drivers I've had a long time).

The memory issues may not be targeting Device Manager/PortMixer, it's just what the testers are focusing on. Are there any other telltale signs?

Any updates on testing?

(In reply to comment #125)
> Any updates on testing?
Not getting much response lately, except that the Art Pro guy "occasionally" gets the conflation and/or inability to record from non-mapped mobo inputs, and this happens quite regularly for the SoundBlaster guy, but it is now significantly less common for him than it was before your last changes. He thinks it helps to rescan before starting to record. 

I seem to be OK now on Win 7 x64 in so far as I haven't yet seen either of the above issues since your last changes (but I haven't recorded much).    

I assume we haven't really found the bug but we are making it harder for it to trigger? 

Depending what happens after 1.3.13 I guess this could be demoted thereafter, but we ought to get it out in the wild on many more systems before deciding on that.

A friend donated an older win7 machine (32 bit) to me, which has a realtek card.  Still can't rep this bug when using the behringer uca 202.
Any incoming reports from 1.3.13 post release?

(In reply to comment #127)
> Any incoming reports from 1.3.13 post release?
I've only seen one new report that looks like the issues in the current release note (Win 7 x64 with an unknown USB turntable, Audio Cache on, turning it off appeared to stop the problem). Of the people who tested in 1.3.13 alpha and have moved to 1.3.13 Beta, the SoundBlaster and Snowball people are still in touch and see the problems occasionally if they don't rescan for a long time in an Audacity session. I have had no issues since I last reported. I think we could demote this to P3 now - anyone disagree?

The issue I have seen (6 reports on Win Vista or 7) is that after upgrading to 1.3.13 from 1.2 or previous Beta, 1.3.13 gives "error opening sound device" when trying to record where the previous version doesn't (even if you go straight back to previous version after 1.3.13 then record). The issue is apparently solved by Transport > Rescan Audio Devices, or go to "Sound" and click OK (without enabling or disabling inputs). This seems to affect motherboard devices whether or not USB devices are connected. Where I know about drivers, the complainants had generic Windows drivers for the motherboard device. So I guess this needs another P3 and release note. 

Can you make stereo recording the default, Michael as it was before these changes (not mono)? This issue was raised on -devel in the run-up to 1.3.13 Beta, but could not be changed because it wasn't a P2. It would save raising a separate bug for it.

(In reply to comment #128)

Sorry it took a while to get to this.
Glad to hear there are less people reporting.  Hopefully this correlates to less people affected by the bug.

Please demote if you think it could be.
Also please open a new bug for the other issues - the 'steps to reproduce' that tend to get left out unless a new bug is created is very helpful for me for both what to test and what the specifics of the bug is.  For example I had some trouble finding the discussion you referred to, and I wasn't sure what 'stereo default' meant and this might be better sorted out with a new bug.  If the concern is that I won't fix it because it's not P2 but still a regression caused by my fix you can spam my email and I will look at it.

I changed the 'initial' default to stereo.  This only affects a fresh .cfg.

I checked 1.3.11 and if you have mono rec channels and switch to a device that goes to stereo it doesn't 'upgrade' to stereo.  I didn't change this part so HEAD still matches 1.3.11.  Also 1.3.11 doesn't seem to gracefully handle going from a stereo device to a device that only supports mono, (but HEAD handles this case).

This thread is too long to read/absorb.  Please summarise any remaining issues or clear/demote.

Thanks
Martyn

(In reply to comment #129)
REOPENED as P3 "Occasional corruption in list of motherboard inputs when USB device connected" (current release note already refers to that issue).  

> I changed the 'initial' default to stereo.  This only affects a fresh .cfg.
Thanks. That was all I had in mind.

> I checked 1.3.11 and if you have mono rec channels and switch to a device that
> goes to stereo it doesn't 'upgrade' to stereo.  I didn't change this part so
> HEAD still matches 1.3.11.  Also 1.3.11 doesn't seem to gracefully handle 
> going from a stereo device to a device that only supports mono, (but HEAD 
> handles this case).

Unfortunately I am not clear what the "upgrade" issue is. Do you have input channels = 1 when you are recording from a mono device (I presume into a mono input) and then change to a stereo device recording into a stereo input? 

Clearly the input channels combo box doesn't detect if a device is mono or stereo (user would have to change it) and I guess you don't mean that. Can you please start a new PX Review bug with steps to reproduce?    

----

I split off the residual issue "Error opening input device on upgrading from < 1.3.13, requiring device rescan" to bug 417 (P3 with its own release note). 

New bug 424 started (P3, Win Vista/7 and only noticed recently) "Changing Host reverts changes in selected devices". 

I note here two recently reported cases on Win XP SP3 with a Realtek AC97 mobo device - when Audacity is opened and/or exited, changes are made to the motherboard device (in one case, the default input device switches to "CD", in another the microphone playback is set to "mute"). I have no information on the sound device drivers these people have so of course it could just be bad drivers.

(In reply to comment #81)
> There are still problems (on XP) when changing the default while audacity is 
> running.  This appears to be due to a portaudio bug.  I have contacted them; 
> not sure if it can be easily resolved. I committed a workaround for this case - 
> rescanning devices (under transport menu).  
This XP bug appears to be displaying extra symptoms since tested here. New bug started to track this at Bug 435 (P3) "Changing Windows default devices in Audacity session breaks recording or playback until rescan".

On my x86 Win 7 laptop I just changed Firefox 9 back from high to normal priority, launched Audacity, plugged in USB turntable, Transport > Rescan Audio Devices. USB Audio CODEC appeared in the input but then the whole of the list was "mirrored" (a duplicate) below. Only the upper set of inputs recorded, others gave "error opening sound device". The mirror disappeared when I rescanned again.

The only person I have been in touch with meantime is one of the Snowball USB mic users. He got much the same as before (occasional "mirrors" if he left Audacity open for several days, Snowball connected all the time and never rescanned. He now uses other software (not because of this, but he wants real time effects).

I have  seen this - and I use a USB device on both my Windows laptop (and my earlier XP and W7 laptops) and my Macbook.

I don't recall ant posts in the past few years about this on the forum - I propse we close this moonphase bug

(In reply to Peter Sampson from comment #134)
OOPS should have read "I have NEVER seen this ..."

My mouse is getting a little "sticky" and making odd selections :-(

I agree with Peter in comment #135.  We can create a new bug if we see anything similar in future.

CLOSED WORKSFORME