http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #8 from Jörg Höhle hoehle@users.sourceforge.net 2012-02-25 17:37:26 CST ---
ALSA lib .../src/pcm/pcm_dmix.c:1018:(snd_pcm_dmix_open) unable to open slave alsa_try_open "default" failed to open: -16 (Dispositivo o recurso ocupado). alsa_try_open "plughw:0,0" failed to open: -16 (Dispositivo o recurso ocupado). ALSA lib .../src/pcm/pcm_dmix.c:1018:(snd_pcm_dmix_open) unable to open slave alsa_try_open "default" failed to open: -16 (Dispositivo o recurso ocupado). alsa_try_open "plughw:0,0" failed to open: -16 (Dispositivo o recurso ocupado). AUDDRV_GetAudioEndpoint "plughw:0,1" 0x124890 0 0x32fb38 AUDDRV_GetAudioEndpoint "plughw:2,0" 0x124928 0 0x32fb38 AUDDRV_GetAudioEndpoint "plughw:2,1" 0x124928 0 0x32fb38
plughw:0,1 is the device that got used for most tests. Is that the Jack one? Why are other ones busy? Is that a case where a device remains open for a couple of seconds, preventing access to the low-level device? I believe that an inaccessible "default" caused no sound in past versions of Wine.
As "default" is the first device accessed, this must have another reason. Why is default=dmix+dsnoop not accessible on your system? Does speaker-test -Ddefault work for you?
Is this all because dmix wants to use hw:0 which is inaccessible too because Jackd sits on it? Shouldn't dmix go through Jack too?
../../../tools/runtest -q -P wine ...
Please supersede the log (make the old one obsolete) with: ../../../tools/runtest -i -v -P wine -M mmdevapi.dll -T ../../.. -p mmdevapi_test.exe.so render.c >/tmp/render.log 2&>1 Does it stutter?
trace:alsa:alsa_write_data pad: 184 warn:alsa:alsa_write_best_effort writei failed, recovering: -32 (Tubería rota) ALSA lib ../../../src/pcm/pcm.c:7316:(snd_pcm_recover) underrun occurred
I'd say this is a symptom of clock skew because CreateTimerQueue callback get more and more late. You'll certainly hear random crackling/choppy sound from the interactive test, thus from all w7 apps that use XAudio2. What about the patch from bug #28723, comment #130?
AudioClient_Initialize ALSA buffer: 1920 frames AudioClock_GetPosition frames written: 48000, held: 480, avail: 1256, delay: 492 state 3, pos: 47520
Wow, <11ms latency. Clearly Jack tries to keep it tiny. OTOH, Jack is lying. Delay cannot be less than the 1920 - 1256 = 664 frames in the ALSA buffer. By construction, http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#ga0d9e14a4b... snd_pcm_delay yields at least the frames lying in the ALSA buffer, that is all those waiting to be played. Either that or Jack's different approach causes it to keep and count data in the ALSA buffer after it's been played, reporting a smaller avail compared to typical hw:0 devices.