[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: wine-bugs(a)winehq.org ReportedBy: naylor.b.david(a)gmail.com CC: gerald(a)pfeifer.com, aeikum(a)codeweavers.com 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). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27917 --- Comment #1 from Andrew Eikum <aeikum(a)codeweavers.com> 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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27917 --- Comment #2 from Andrew Eikum <aeikum(a)codeweavers.com> 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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27917 --- Comment #3 from David Naylor <naylor.b.david(a)gmail.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27917 --- Comment #4 from Andrew Eikum <aeikum(a)codeweavers.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27917 --- Comment #5 from David Naylor <naylor.b.david(a)gmail.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27917 --- Comment #6 from David Naylor <naylor.b.david(a)gmail.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27917 --- Comment #7 from Andrew Eikum <aeikum(a)codeweavers.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27917 Andrew Eikum <aeikum(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED --- Comment #8 from Andrew Eikum <aeikum(a)codeweavers.com> 2011-07-27 13:27:09 CDT --- Should be fixed by e0f1aa0b05b50f9dcc4ee7ea7428997fda168228. Thanks again for the report. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27917 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #9 from Alexandre Julliard <julliard(a)winehq.org> 2011-08-05 12:38:58 CDT --- Closing bugs fixed in 1.3.26. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org