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 pl
Getting closer, I had to change
+/*
+** See if it's a valid playback device
+**--*/
+if (ALSA_TestDeviceForWine(card, device
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 ch
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.
[EMAIL PROTECTED] Winamp $ WINEDEBUG=+wa
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_TestDe
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 a
