[Bug 27917] New: [regression] sound does not work, wine chooses wrong pcm

http://bugs.winehq.org/show_bug.cgi?id=27917

Summary: [regression] sound does not work, wine chooses wrong
                    pcm
           Product: Wine
           Version: 1.3.25
          Platform: x86
        OS/Version: FreeBSD
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: directx-dsound
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]
                CC: [e-mail], [e-mail]

Created an attachment (id=35717)
 --> (http://bugs.winehq.org/attachment.cgi?id=35717)
"+tid,+dsound,+winmm,+mmdevapi,+oss,+alsa,+coreaudio"

After upgrading to 1.3.25 sound stops working, Civ V and winecfg used to test.

Of note is:
# cat /dev/sndstat
FreeBSD Audio Driver (newpcm: 64bit 2009061500/amd64)
Installed devices:
pcm0: <HDA NVidia (Unknown) PCM #0 DisplayPort> (play)
pcm1: <HDA NVidia (Unknown) PCM #0 DisplayPort> (play)
pcm2: <HDA NVidia (Unknown) PCM #0 DisplayPort> (play)
pcm3: <HDA NVidia (Unknown) PCM #0 DisplayPort> (play)
pcm4: <HDA Realtek ALC892 PCM #0 Analog> (play/rec) default
pcm5: <HDA Realtek ALC892 PCM #1 Analog> (play/rec)
pcm6: <HDA Realtek ALC892 PCM #2 Digital> (play)
pcm7: <HDA Realtek ALC892 PCM #3 Digital> (play)

The default device, pcm4, is the device that actually plays sound however wine
uses pcm0 (as reported by winecfg).

[Bug 27917] [regression] sound does not work, wine chooses wrong pcm

http://bugs.winehq.org/show_bug.cgi?id=27917

--- Comment #1 from Andrew Eikum  2011-07-27 08:08:28 CDT ---
Thanks for the very nice report.

I think this is technically a bug in FreeBSD's OSS implementation. According to
the OSS 4.2 spec[1], the oss_audioinfo.caps member for the default device
should contain the PCM_CAP_DEFAULT flag. If you look at your log, you'll see
every "caps:" line for each device contains exactly the same flags, modulo
input vs. output flags. Wine has logic to handle this flag, but if it's never
given, then it just picks the first one. That's what's happening here.

On the other hand, if you follow the PCM_CAP_DEFAULT link[2], you find that it
says that flag is completely useless! Why even have it then??? Audio API
developers are universally terrible. I'm getting really tired of this.

So it seems there's no reliable way to get the default device. I wonder if
there's a way to get the "true" device behind /dev/dsp, like [2] recommends.
I'll investigate along these lines and report back.

[1] http://manuals.opensound.com/developer/audio_capabilities.html
[2] http://manuals.opensound.com/developer/PCM_CAP_DEFAULT.html

[Bug 27917] [regression] sound does not work, wine chooses wrong pcm

http://bugs.winehq.org/show_bug.cgi?id=27917

--- Comment #2 from Andrew Eikum  2011-07-27 09:58:49 CDT ---
Created an attachment (id=35718)
 --> (http://bugs.winehq.org/attachment.cgi?id=35718)
wineoss.drv: Choose default device using different method

Okay, here's an attempt to fix this. It works on my system. Can you test this
on yours?

[Bug 27917] [regression] sound does not work, wine chooses wrong pcm

http://bugs.winehq.org/show_bug.cgi?id=27917

--- Comment #3 from David Naylor  2011-07-27 10:15:01 CDT ---
Thanks for your quick response.

Reading [2] I interpret that flag indicating a device's suitability as a
default device, not that the device *is* the default device.  Nor does it say
only one device may have this flag set (and only implies multiple devices may
have the flag set).  What is the intended use of PCM_CAP_DEFAULT?  And how is
it used in other oss implementations?

Does not the second last paragraph imply /dev/dsp should be used as the default
device?

I looked through the source code for FreeBSD and found:

# grep -r PCM_CAP_DEFAULT .
./sys/sys/soundcard.h:# define PCM_CAP_DEFAULT          0x40000000      /*
"Default" device */
./sys/sys/soundcard.h:#define DSP_CAP_DEFAULT           PCM_CAP_DEFAULT
# grep -r DSP_CAP_DEFAULT .
./sys/sys/soundcard.h:#define DSP_CAP_DEFAULT           PCM_CAP_DEFAULT

Which I interpret that FreeBSD does not even set *_CAP_DEFAULT for any device. 
FreeBSD does provide a way to determine the default device (and change it) via
the sysctl "hw.snd.default_unit".  I think there is definitely a bug in
FreeBSD's OSS implementation and will gladly report it.

I looked through the trace and found two different caps: 23200 and 13200.  The
first occurrence of 13200 is the default device.  I cannot say if that is
significant or just chance.

I have made a patch to set PCM_CAP_DEFAULT for the default device.  I will test
it, then the one you just posted, and report back.

[Bug 27917] [regression] sound does not work, wine chooses wrong pcm

http://bugs.winehq.org/show_bug.cgi?id=27917

--- Comment #4 from Andrew Eikum  2011-07-27 10:25:12 CDT ---
(In reply to comment #3)
> Reading [2] I interpret that flag indicating a device's suitability as a
> default device, not that the device *is* the default device.  Nor does it say
> only one device may have this flag set (and only implies multiple devices may
> have the flag set).  What is the intended use of PCM_CAP_DEFAULT?  And how is
> it used in other oss implementations?

I don't know. If audio API developers would actually document their APIs, we
wouldn't have to ask this question. The fact that FreeBSD never sets it makes
me think it's not used by anyone. It's a wonder why the OSS devs thought to add
it...
> Which I interpret that FreeBSD does not even set *_CAP_DEFAULT for any device. 
> FreeBSD does provide a way to determine the default device (and change it) via
> the sysctl "hw.snd.default_unit".  I think there is definitely a bug in
> FreeBSD's OSS implementation and will gladly report it.

I think your interpretation of the PCM_CAP_DEFAULT flag is correct. That is,
it's entirely optional, and no one uses it. I'm not sure what behavior FreeBSD
should do here. The docs say that it means the device is "suitable to be used
as a default audio device" without defining what any of that means.
> I looked through the trace and found two different caps: 23200 and 13200.  The
> first occurrence of 13200 is the default device.  I cannot say if that is
> significant or just chance.

Nah, 0x20000 is SND_PCM_OUTPUT and 0x10000 is SND_PCM_INPUT. Nothing
interesting there, just telling you what flow directions the device supports.
> I have made a patch to set PCM_CAP_DEFAULT for the default device.  I will test
> it, then the one you just posted, and report back.

I think it's a Wine bug. We should not be depending on PCM_CAP_DEFAULT. The
patch I attached uses /dev/dsp to find the default device like the docs
suggest.

[Bug 27917] [regression] sound does not work, wine chooses wrong pcm

http://bugs.winehq.org/show_bug.cgi?id=27917

--- Comment #5 from David Naylor  2011-07-27 10:54:38 CDT ---
(In reply to comment #4)
> (In reply to comment #3)
> > Reading [2] I interpret that flag indicating a device's suitability as a
> > default device, not that the device *is* the default device.  Nor does it say
> > only one device may have this flag set (and only implies multiple devices may
> > have the flag set).  What is the intended use of PCM_CAP_DEFAULT?  And how is
> > it used in other oss implementations?
>
> I don't know. If audio API developers would actually document their APIs, we
> wouldn't have to ask this question. The fact that FreeBSD never sets it makes
> me think it's not used by anyone. It's a wonder why the OSS devs thought to add
> it...

Looking through the oss source from 4Front Technologies it appears they do set
the PCM_CAP_DEFAULT flag:
# grep -r PCM_CAP_DEFAULT .
./kernel/framework/audio/oss_audio_core.c:       * PCM_CAP_DEFAULT devices. A
new ADEV_ flag should be defined
./kernel/framework/audio/oss_audio_core.c:        info |= PCM_CAP_DEFAULT;
./include/soundcard.h:# define PCM_CAP_DEFAULT          0x40000000      /*
"Default" device */
./include/soundcard.h:#define DSP_CAP_DEFAULT           PCM_CAP_DEFAULT

however it appears they set it for every device, so just as useful as the
FreeBSD implementation.

[Bug 27917] [regression] sound does not work, wine chooses wrong pcm

http://bugs.winehq.org/show_bug.cgi?id=27917

--- Comment #6 from David Naylor  2011-07-27 12:00:32 CDT ---
(In reply to comment #2)
> Created an attachment (id=35718)

--> (http://bugs.winehq.org/attachment.cgi?id=35718) [details]
> wineoss.drv: Choose default device using different method
>
> Okay, here's an attempt to fix this. It works on my system. Can you test this
> on yours?

Yes, this works on my system with winecfg, for Civ V I had to change hardware
acceleration from Emulated to Full to get sound to work.

[Bug 27917] [regression] sound does not work, wine chooses wrong pcm

http://bugs.winehq.org/show_bug.cgi?id=27917

--- Comment #7 from Andrew Eikum  2011-07-27 12:12:33 CDT ---
Okay, cool. The Civ V issue is a separate bug. Audio should work regardless of
the acceleration setting. (To be honest, I would really like to remove the Full
Acceleration setting entirely. It's a leftover from the old architecture and
creates confusion and conflicting bug reports.)

If you're interested in helping fix the Civ V Emulation mode bug, creating a
new bug with the same log channels with dsound in emulation mode would be
helpful.

[Bug 27917] [regression] sound does not work, wine chooses wrong pcm

http://bugs.winehq.org/show_bug.cgi?id=27917

Andrew Eikum  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED

--- Comment #8 from Andrew Eikum  2011-07-27 13:27:09 CDT ---
Should be fixed by e0f1aa0b05b50f9dcc4ee7ea7428997fda168228. Thanks again for
the report.

[Bug 27917] [regression] sound does not work, wine chooses wrong pcm

http://bugs.winehq.org/show_bug.cgi?id=27917

Alexandre Julliard  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #9 from Alexandre Julliard  2011-08-05 12:38:58 CDT ---
Closing bugs fixed in 1.3.26.