winealsa: 6 Channel Audio

[Jonathan McCrohan]

Hi,

Using foobar2000 (Wine 1.3.31) to output 6 channel audio via WASAPI, I
get an error in foobar2000, and the following Wine errors in the terminal:

fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000
channels, pretending there's only 2 channels

However, when using a patched version of Wine with hardcoded support for
6 channel audio, foobar2000 6 channel audio works correctly (patch
attached). While this works, it is just a hack and doesn't fix the
underlying issue; the additional 9,994 audio channels. This also merely
just changes the error message from 2s channel to 6 channels:

fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000
channels, pretending there's only 6 channels

Would someone with a better knowledge of Wine and/or ALSA be able to
assist me in tracking down the source of this bug?

Thanks,
Jonathan

[Chris Robinson]

On Sunday, October 23, 2011 8:28:45 PM Jonathan McCrohan wrote:
> Would someone with a better knowledge of Wine and/or ALSA be able to
> assist me in tracking down the source of this bug?

Hi.

Part of the problem is the way Wine attempts to "detect" a default format from 
ALSA. ALSA doesn't report a default format, though, so Wine attempts to see 
what it's capable of and reports that instead. Apparently ALSA is capable of 
handling up to 10,000 channels, and Wine has no idea how to report that back 
to the Windows app.

IMO, the "fix" would be to make winealsa default to something sane, like 
44.1khz 16-bit stereo. A configuration option (in winecfg/control panel) would 
be needed to set it into a different mode. Windows has something similar to 
this for its own audio device configuration in the control panel.

But, there's an additional complication. The order Windows expects for >4 
channels is different than what ALSA provides. For example, ALSA places the 
front-center/lfe channels after the rear-left/right, while Windows places them 
after front-left/right. So either Wine will need to tell ALSA to expect a 
different order (I'm not sure if you can in an easy way), or Wine will have to 
reorder the samples itself before writing to the device.

[Andrew Eikum]

On Sun, Oct 23, 2011 at 05:57:04PM -0700, Chris Robinson wrote:
> On Sunday, October 23, 2011 8:28:45 PM Jonathan McCrohan wrote:
> > Would someone with a better knowledge of Wine and/or ALSA be able to
> > assist me in tracking down the source of this bug?
>
> Part of the problem is the way Wine attempts to "detect" a default format from 
> ALSA. ALSA doesn't report a default format, though, so Wine attempts to see 
> what it's capable of and reports that instead. Apparently ALSA is capable of 
> handling up to 10,000 channels, and Wine has no idea how to report that back 
> to the Windows app.
>
> IMO, the "fix" would be to make winealsa default to something sane, like 
> 44.1khz 16-bit stereo.

I agree, this is a better solution than trying to detect it from the
backends. Looking at >2-channel audio setups is near the top of my
TODO list; Scott Ritchie even asked me about it at WineConf this year.
Reworking GetMixFormat() is probably going to be part of that.

Jonathan: If you are confident with the ALSA API, I would be happy to
review a patch that does this and/or fixes multichannel audio. If you
aren't confident with ALSA and value your sanity, I would suggest you
stay far, far away :)
>                    A configuration option (in winecfg/control panel) would 
>
> be needed to set it into a different mode. Windows has something similar to 
> this for its own audio device configuration in the control panel.

My reaction to this is "urrrrrrrghhhhhhh". I'd much rather tuck it
away in a registry entry than put it in winecfg for everyone to mess
with. I was surprised to see that option on my Win 7 VM, although the
control is actually inactive.
> But, there's an additional complication. The order Windows expects for >4 
> channels is different than what ALSA provides. For example, ALSA places the 
> front-center/lfe channels after the rear-left/right, while Windows places them 
> after front-left/right. So either Wine will need to tell ALSA to expect a 
> different order (I'm not sure if you can in an easy way), or Wine will have to 
> reorder the samples itself before writing to the device.

Yeah, remapping the channels in winealsa.drv is probably the solution,
unfortunately. I'll know more once I start investigating the various
backends' multichannel support.

Andrew

[Chris Robinson]

On Monday, October 24, 2011 8:08:58 AM Andrew Eikum wrote:
> On Sun, Oct 23, 2011 at 05:57:04PM -0700, Chris Robinson wrote:
> >                    A configuration option (in
> >
> > winecfg/control panel) would be needed to set it into a different mode.
> > Windows has something similar to this for its own audio device
> > configuration in the control panel.
>
> My reaction to this is "urrrrrrrghhhhhhh". I'd much rather tuck it
> away in a registry entry than put it in winecfg for everyone to mess
> with. I was surprised to see that option on my Win 7 VM, although the
> control is actually inactive.

Personally, I don't think users should be asked to manually edit the registry 
to enable 4-channel or 5.1 surround sound, to select 48khz playback, or to 
enable 24- or 32-bit output. They're not uncommon settings, so many people may 
want to use it, but not common enough to make them default. A control panel 
applet would also provide a nice place to test the separate channels to make 
sure they're mapping correctly.

[Andrew Eikum]

On Mon, Oct 24, 2011 at 06:26:18AM -0700, Chris Robinson wrote:
> On Monday, October 24, 2011 8:08:58 AM Andrew Eikum wrote:
> > On Sun, Oct 23, 2011 at 05:57:04PM -0700, Chris Robinson wrote:
> > >                    A configuration option (in
> > >
> > > winecfg/control panel) would be needed to set it into a different mode.
> > > Windows has something similar to this for its own audio device
> > > configuration in the control panel.
> >
> > My reaction to this is "urrrrrrrghhhhhhh". I'd much rather tuck it
> > away in a registry entry than put it in winecfg for everyone to mess
> > with. I was surprised to see that option on my Win 7 VM, although the
> > control is actually inactive.
>
> Personally, I don't think users should be asked to manually edit the registry 
> to enable 4-channel or 5.1 surround sound, to select 48khz playback, or to 
> enable 24- or 32-bit output. They're not uncommon settings, so many people may 
> want to use it, but not common enough to make them default. A control panel 
> applet would also provide a nice place to test the separate channels to make 
> sure they're mapping correctly.

To be frank, what I want to avoid is giving users a ton of options
with which to screw up their audio config, promptly forget about
changing those settings, and then having to sort out their bug reports
("Can you set this to X and that to Y and get yet another log,
please?"). Tucking stuff away in the registry makes it a pain to screw
up their config, which means they'll probably turn to submitting bug
reports with the default config first, which is exactly what I want.

There are other problems with overriding GetMixFormat(). For example,
it should really be a per-device (and therefore per-backend) setting.
Can you imagine the dialog for that?

What I really want, and what I tried to do when making the drivers, is
GetMixFormat() to report the format that most accurately represents
the device. I want the format reported by GetMixFormat() to require as
near to no resampling, no channel remapping, and no bit depth changes
as possible on its path from the application to the hardware. Then
IsFormatSupported() and Initialize() will deal with conversions, if
need be. Unfortunately, it seems very difficult to get this
information out of most of the backends, which is why we have this
"10000 channels" nonsense.

I'm unsure what the best solution to this problem is. I'm open to
suggestions.

Andrew