Attached is a fairly sizable patch that revamps the way Alsa initialization is done.
With this patch, Wine now does the following: scan all cards given by Alsa (not brute force 0-5), respect alsa defaults and environment variable overrides, probe to see if a reported Alsa device is useful (e.g. strip my Modem from the list of reported sound cards), and provide a mechanism for an end user to explicitly configure Wine to use Alsa.
The default configuration values should 'just work' in most cases, but the following registry values are permitted to provide finer control:
** [Software\Wine\Wine\Config\ALSA] ** AutoScanCards Whether or not to scan all known sound cards ** and add them to Wine's list (default yes) ** AutoScanDevices Whether or not to scan all known PCM devices ** on each card (default no) ** UsePlugDevice Whether or not to use the plug:hw device, ** which automagically handles rate conversion (def yes) ** DeviceCount If present, specifies the number of hard coded ** Alsa devices to add to Wine's list; default 0 ** DevicePCMn Specifies the Alsa PCM devices to open for ** Device n (where n goes from 1 to DeviceCount) ** DeviceCTLn Specifies the Alsa control devices to open for ** Device n (where n goes from 1 to DeviceCount) ** ** Using AutoScanCards no, and then Devicexxx info ** is a way to exactly specify the devices used by Wine.
I'd appreciate anyone passionately interested in Alsa (Kevin? Robert?) taking the time to try this patch.
I've tried to 'do no harm', but this is a material enough change that I'm not yet comfortable submitting it to wine-patches.
fwiw, there is a (fairly thin) thread on the alsa dev lists regerading this here: http://sourceforge.net/mailarchive/forum.php?thread_id=7452725&forum_id=...
Cheers,
Jeremy
On Monday 13 June 2005 10:01 am, Jeremy White wrote:
Attached is a fairly sizable patch that revamps the way Alsa initialization is done.
In ALSA_TestDeviceForWine, the call to snd_pcm_open blocks if I have any applications currently using my sound card, and does not complete until all other apps accessing alsa close, effectively freezing wine mixing is not supported on my card, so only one application can open hw at a time, all others will block on snd_pcm_open it does, however, work with [ALSA] "AutoScanCards"="n" "DeviceCount"="1" "DevicePCM1"="default" "DeviceCTL1"="default"
Sound card is standard AC'97 that comes with nForce4 # lspci -v -s 00:04.0 0000:00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio Controller (rev a2) Subsystem: ASUSTeK Computer Inc.: Unknown device 812a Flags: bus master, 66Mhz, fast devsel, latency 0, IRQ 22 I/O ports at dc00 I/O ports at e000 [size=256] Memory at d2003000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2
What happens if you change the snd_pcm_open line to tweak the 3rd parameter from 0 to SND_PCM_NONBLOCK?
Cheers,
Jer
Kevin Koltzau wrote:
On Monday 13 June 2005 10:01 am, Jeremy White wrote:
Attached is a fairly sizable patch that revamps the way Alsa initialization is done.
In ALSA_TestDeviceForWine, the call to snd_pcm_open blocks if I have any applications currently using my sound card, and does not complete until all other apps accessing alsa close, effectively freezing wine mixing is not supported on my card, so only one application can open hw at a time, all others will block on snd_pcm_open it does, however, work with [ALSA] "AutoScanCards"="n" "DeviceCount"="1" "DevicePCM1"="default" "DeviceCTL1"="default"
Sound card is standard AC'97 that comes with nForce4 # lspci -v -s 00:04.0 0000:00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio Controller (rev a2) Subsystem: ASUSTeK Computer Inc.: Unknown device 812a Flags: bus master, 66Mhz, fast devsel, latency 0, IRQ 22 I/O ports at dc00 I/O ports at e000 [size=256] Memory at d2003000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2
On Monday 13 June 2005 11:49 pm, Jeremy White wrote:
What happens if you change the snd_pcm_open line to tweak the 3rd parameter from 0 to SND_PCM_NONBLOCK?
With that flag set it does get past that point, however it ends up not detecting any devices.
kevin@kevin Winamp $ WINEDEBUG=+wave wine winamp trace:wave:ALSA_TestDeviceForWine Discarding card 0/device 0: (null) [-16(Device or resource busy)] trace:wave:ALSA_TestDeviceForWine Discarding card 0/device 0: (null) [-16(Device or resource busy)] trace:wave:ALSA_widMessage (0, DRVM_INIT, 00000000, 00000000, 00000000); trace:wave:ALSA_widMessage (0, WIDM_GETNUMDEVS, 00000000, 00000000, 00000000); trace:wave:ALSA_wodMessage (0, DRVM_INIT, 00000000, 00000000, 00000000); trace:wave:ALSA_wodMessage (0, WODM_GETNUMDEVS, 00000000, 00000000, 00000000);
What happens if you change the snd_pcm_open line to tweak the 3rd parameter from 0 to SND_PCM_NONBLOCK?
With that flag set it does get past that point, however it ends up not detecting any devices.
Hmm. I'm guessing that this is similar to Wine's behavior before your change to default? If so, could you try the attached patch? It now tries default:X and falls back to plughw:X if default is not available.
Cheers,
Jeremy
Kevin Koltzau wrote:
On Monday 13 June 2005 11:49 pm, Jeremy White wrote:
What happens if you change the snd_pcm_open line to tweak the 3rd parameter from 0 to SND_PCM_NONBLOCK?
With that flag set it does get past that point, however it ends up not detecting any devices.
Actually, try this one instead. Turns out that if you open a device with default:0 on some versions of alsalib (my laptop, as opposed to my work box), then snd_pcm_name() fails. Sigh.
Jer
On Tuesday 14 June 2005 11:21 pm, Jeremy White wrote:
Kevin Koltzau wrote: Actually, try this one instead. Turns out that if you open a device with default:0 on some versions of alsalib (my laptop, as opposed to my work box), then snd_pcm_name() fails. Sigh.
Getting closer, I had to change + /*---------------------------------------------------------------- + ** See if it's a valid playback device + **--------------------------------------------------------------*/ + if (ALSA_TestDeviceForWine(card, device, SND_PCM_STREAM_PLAYBACK) == 0)
to check for < 0 (would return -16 when it failed), and it detected default and worked great!
One try it was actually able to open hw:0,0, though the format I was sending through was unsupported and ended up failing to play. It would have worked if plug:hw:0,0 was opened instead as plug will do format conversion. I would prefer default in that case also however, as wine was blocking all my other audio apps from working. Always checking for default, even if hw works, might be a good idea.
Also for + sprintf(ctlname, "hw:%d", fixedctlcard == -1 ? card : fixedctlcard); + rc = snd_ctl_open(&ctl, ctlname, SND_CTL_NONBLOCK); the case default was used, you should open default as well rather then hw:0
Getting closer, I had to change
/*----------------------------------------------------------------** See if it's a valid playback device**--------------------------------------------------------------*/if (ALSA_TestDeviceForWine(card, device, SND_PCM_STREAM_PLAYBACK) == 0)to check for < 0 (would return -16 when it failed), and it detected default and worked great!
Well, then you've essentially noop-ed that line. That line serves the function of stripping out odd ball devices (like my Modem), so I am reluctant to lose it.
The rc of -16 is EBUSY.
To be honest, I find it odd that you're getting a success while the sound card is in use; in my testing, any attempt to open a pcm that is in use generates a -16 return code, whether it be default:0 or plughw:0 or hw:0. The current Wine code should fail in that case.
I'm going to send you a quick test program off list, if you don't mind trying an experiment for me, that would be great.
One try it was actually able to open hw:0,0, though the format I was sending through was unsupported and ended up failing to play. It would have worked if plug:hw:0,0 was opened instead as plug will do format conversion. I would prefer default in that case also however, as wine was blocking all my other audio apps from working. Always checking for default, even if hw works, might be a good idea.
Well, the rationale now is that we try default:X first, and then fall back to plughw as the backup. The direct hw device is used only when configured (and when we probe to see if the device is rational).
Also for
sprintf(ctlname, "hw:%d", fixedctlcard == -1 ? card : fixedctlcard);rc = snd_ctl_open(&ctl, ctlname, SND_CTL_NONBLOCK);the case default was used, you should open default as well rather then hw:0
Hmm. You raise a good point. The plughw device does not function as a ctl device, so in 'traditional' alsa, you always had to open hw:X as the ctl device.
Gack. I want some of the drugs these Alsa developers are using...
Cheers,
Jer
On Wednesday 15 June 2005 10:10 pm, Jeremy White wrote:
The rc of -16 is EBUSY.
To be honest, I find it odd that you're getting a success while the sound card is in use; in my testing, any attempt to open a pcm that is in use generates a -16 return code, whether it be default:0 or plughw:0 or hw:0. The current Wine code should fail in that case.
The sound card is in use by the dmix/dsnoop plugin. my "default" device is actually a chain of plugins, a striped down version of my .asoundrc is (let me know if you want my full config) pcm.output { type dmix slave.pcm "hw:0,0" } pcm.input { type dsnoop slave.pcm "hw:0,0" } pcm.duplex { type asym playback.pcm "output" capture.pcm "input" } pcm.!default { type plug slave.pcm "duplex" } ctl.!default { type hw card 0 }
so default goes through asym, which joins dsnoop and dmix, which then actually access my hardware.
This is a pretty common config for cards that do not support hardware mixing, IMO.
I'm going to send you a quick test program off list, if you don't mind trying an experiment for me, that would be great.
Send away
-
Jeremy White -
Kevin Koltzau