[Bug 29294] No sound with ALSA loopback devices

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=29294

--- Comment #8 from Jörg Höhle <hoehle at 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#ga0d9e14a4be65209eb549e48a9f07302
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.

-- 
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.