http://bugs.winehq.org/show_bug.cgi?id=27917
--- Comment #4 from Andrew Eikum aeikum@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.