I'm working on Bug 14559 and have run into an interesting UI problem.
In WinMM, there are three "classes" of devices: waveIn, waveOut, and mixer. Windows 7's WinMM implementation provides one mixer for each waveIn and waveOut device. The "WCHAR caps.szPname[32]" field for the matching mixer and waveIn/Out device are the same. Some applications, in this case Rosetta Stone 3, use the matching szPname fields to determine which mixer to associate with which device.
The problem turns up when we have duplicate input and output device names. Consider:
waveOut: 0: default 1: HDA Intel Analog 2: HDA Intel Digital
waveIn: 0: default 1: HDA Intel Analog
mixer: 0: default 1: HDA Intel Analog 2: HDA Intel Digital 3: default 4: HDA Intel Analog
Rosetta Stone chooses waveIn[0] and starts iterating over the mixers' szPname fields, finding that mixer[0] matches. But, mixer[0] is actually associated with the waveOut default, not the waveIn default. Bad things happen.
Windows 7 solves this problem implicitly by providing unique device names at the MMDevAPI level. For instance, the input device is Microphone and the output devices are Stereo and Headphones. Hacking the registry to force duplicate MMDevAPI device names actually does result in duplicate mixer names. But Wine's backends don't provide this kind of information, so we simply provide the ALSA device name as the device's name.
As an attempt to solve this in Wine, I added a prefix to each MMDevice indicating its flow direction. The unique identifier must be a prefix, as WinMM's szPname field truncates at 31 characters. This gives WinMM device names like:
waveOut: 0: Out: default 1: Out: HDA Intel Analog 2: Out: HDA Intel Digital
This solves the Rosetta Stone issue, as you can see in the bug. But when testing this in other applications, it quickly becomes silly. Audacity 1.3 adds its own "Out: " prefix to WinMM device names, creating "Out: Out: default" in the UI.
Dynamically adding prefixes only if a duplicate device is present causes issues with duplicates appearing/disappearing. Trying to remember if a duplicate has ever been present is quite "ugly" in code, requiring storing that kind of information in the registry.
So I don't know what to do. Have ugly, redundant device names? Leave Rosetta Stone broken, as it is arguably an application bug? Try to guess at the device type, and insert names like "Speakers" and "Microphone" into the MMDevAPI device name, even if that might be wrong?
Thoughts?
Andrew
On Mar 27, 2012, at 11:04 AM, Andrew Eikum wrote:
I added a prefix to each MMDevice indicating its flow direction.
This solves the Rosetta Stone issue, as you can see in the bug. But when testing this in other applications, it quickly becomes silly. Audacity 1.3 adds its own "Out: " prefix to WinMM device names, creating "Out: Out: default" in the UI.
Meh. I don't think that's a particularly troublesome side effect. If no better solution presents itself, then I say this is the least bad of the alternatives.
That said...
The unique identifier must be a prefix, as WinMM's szPname field truncates at 31 characters.
Is it really likely that identifiers will not leave any characters to spare? Anyway, since WinMM is already arbitrarily truncating them, you can truncate them even earlier at 29 characters and suffix with as much of " output" or " input" as will fit.
Another approach is to prefix but using an obscure "code" which won't look silly when applications also prefix the device name. For example, the ALSA driver might use "WAO" and "WAI" (for "Wine ALSA Output" and "Wine ALSA Input", respectively) or whatever. These codes will be inscrutable, but not obviously redundant with an application-provided "Out: " prefix. And users are already somewhat used to inscrutable terms in device names (for example, "HDA" meant nothing to me until I looked it up).
Regards, Ken
On Wednesday 28 March 2012 04:43:54 pm Ken Thomases wrote:
On Mar 27, 2012, at 11:04 AM, Andrew Eikum wrote:
I added a prefix to each MMDevice indicating its flow direction.
This solves the Rosetta Stone issue, as you can see in the bug. But when testing this in other applications, it quickly becomes silly. Audacity 1.3 adds its own "Out: " prefix to WinMM device names, creating "Out: Out: default" in the UI.
Meh. I don't think that's a particularly troublesome side effect. If no better solution presents itself, then I say this is the least bad of the alternatives.
That said...
The unique identifier must be a prefix, as WinMM's szPname field truncates at 31 characters.
Is it really likely that identifiers will not leave any characters to spare? Anyway, since WinMM is already arbitrarily truncating them, you can truncate them even earlier at 29 characters and suffix with as much of " output" or " input" as will fit.
Another approach is to prefix but using an obscure "code" which won't look silly when applications also prefix the device name. For example, the ALSA driver might use "WAO" and "WAI" (for "Wine ALSA Output" and "Wine ALSA Input", respectively) or whatever. These codes will be inscrutable, but not obviously redundant with an application-provided "Out: " prefix. And users are already somewhat used to inscrutable terms in device names (for example, "HDA" meant nothing to me until I looked it up).
Regards, Ken
Maybe add some extra checks like: - If it's input and it doesn't already contain (case insensitive) "input" or "capture" or "microphone" append " Input" (as much as it fits in buffer) - If it's output and it doesn't already contain (case insensitive) "output" or "playback" or "speaker" append " Output" (as much as it fits in buffer)
Paul
-
Andrew Eikum -
Ken Thomases -
Paul Chitescu