http://bugs.winehq.org/show_bug.cgi?id=29294
Bug #: 29294 Summary: No sound with ALSA loopback devices Product: Wine Version: 1.3.34 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mmdevapi AssignedTo: wine-bugs@winehq.org ReportedBy: amlopezalonso@gmail.com Classification: Unclassified
I recently set up an ALSA-to-JACK bridge (as described in http://alsa.opensrc.org/Jack_and_Loopback_device_as_Alsa-to-Jack_bridge) in order to route non-JACK apps into JACK. Every sounding non-JACK app (even Flash Player) work flawlessly but Wine outputs no sound (in theory, ALSA loopback devices should behave transparently to Wine).
I'm using git version and every audio app I ran in Wine (even the sound tests in winecfg) shoots several:
fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels
Disabling JACK server plus unloading snd-aloop module restores the sound from Wine.
I'll send more-specific logs upon request.
Regards, Antonio
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #1 from Antonio López amlopezalonso@gmail.com 2011-12-09 18:31:46 CST --- More specifically, there are eight fixmes which matches the number of subdevices per loopback device.
http://bugs.winehq.org/show_bug.cgi?id=29294
Johnny Oskarsson bugzilla@joskar.se changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bugzilla@joskar.se
--- Comment #2 from Johnny Oskarsson bugzilla@joskar.se 2011-12-17 14:51:35 CST --- I can confirm this, with the exception that i get 10 fixmes when opening the Audio tab in winecfg. Changing the number of subdevices in the snd-aloop module has no effect.
Wine is probably the first application that has given me trouble with this setup, ever. And I am quite sure it has worked perfectly in the past (I may be mistaken; It might have been when the JACK module still was available, in which case it was not using the ALSA loopback device at all).
http://bugs.winehq.org/show_bug.cgi?id=29294
kisak42@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kisak42@gmail.com
--- Comment #3 from kisak42@gmail.com 2012-02-06 14:25:23 CST --- I also encounter audio difficulty consistent with this bug. I linked some applications that I can positively confirm are affected, but really this bug is relevant to all applications that use conventional audio output. No other linux porgrams on my system have a problem with the alsa loopback device.
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #4 from kisak42@gmail.com 2012-02-06 14:34:47 CST --- I recommend this bug should be changed to major severity based on the fact it affects most applications that output audio. The flip side of the coin is that there are few users that have a setup with an alsa loopback device, so it should get a low priority.
http://bugs.winehq.org/show_bug.cgi?id=29294
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hoehle@users.sourceforge.ne | |t Target Milestone|--- |1.4.0
--- Comment #5 from Jörg Höhle hoehle@users.sourceforge.net 2012-02-23 15:36:40 CST --- 1. Please set the new registry key ALSAOutputDevices to the name of your duplex device if you did not override !default or select the device in winecfg. Is it listed there? 2. Please attach the log from: cd dlls/mmdevapi/tests/; rm render.ok WINETEST_INTERACTIVE=1 WINETEST_DEBUG=2 WINEDEBUG=+alsa,+tid,+timestamp,+mmdevapi make render.ok >> /tmp/render.log 2>&1
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #6 from Antonio López amlopezalonso@gmail.com 2012-02-24 18:39:51 CST --- Created attachment 39046 --> http://bugs.winehq.org/attachment.cgi?id=39046 Render.log output
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #7 from Antonio López amlopezalonso@gmail.com 2012-02-24 18:41:30 CST ---
(In reply to comment #5)
First of all, I must say sound is working again in rc4 (probably before) but rather choppy.
- Please set the new registry key ALSAOutputDevices to the name of your duplex
device if you did not override !default or select the device in winecfg. Is it listed there?
Sound devices have been there in winecfg even when there was no sound at all. In my case there are three output devices (default, loopback and digital). For the following I chose default.
- Please attach the log from:
cd dlls/mmdevapi/tests/; rm render.ok WINETEST_INTERACTIVE=1 WINETEST_DEBUG=2 WINEDEBUG=+alsa,+tid,+timestamp,+mmdevapi make render.ok >> /tmp/render.log 2>&1
OK, there you are.
http://bugs.winehq.org/show_bug.cgi?id=29294
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #39046|application/octet-stream |text/plain mime type| |
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.
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #9 from Antonio López amlopezalonso@gmail.com 2012-02-26 18:54:21 CST ---
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.
I don't know why the other devices seem to be busy. I have no other issues with audio apps except with Amarok but probably for other reasons.
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?
speaker-test -Ddefault works fine.
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?
I don't know about the nuts and bolts of the loopback devices. But I can tell you I'm just using the generic asoundrc file shown in http://alsa.opensrc.org/Jack_and_Loopback_device_as_Alsa-to-Jack_bridge just below the "asoundrc definition" entry. The only difference I made was in the loop2jack script: I modified the two lines for system microphone as follows:
jack_connect system:capture_1 ploop:playback_1 jack_connect system:capture_2 ploop:playback_2
../../../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?
This test finishes with no output at all (no sound and an empty render.log).
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?
Applied the patch, recompiled and reinstalled git wine and the stuttering is still there.
Regards, Antonio
http://bugs.winehq.org/show_bug.cgi?id=29294
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aeikum@codeweavers.com
--- Comment #10 from Jörg Höhle hoehle@users.sourceforge.net 2012-02-27 04:46:37 CST ---
an empty render.log
2&>1 should have read 2>&1 as in comment #5 Also, prefer the pair rm render.log; .... >>render.log (use append mode, cf. bug #19125) The test results must appear together with the traces.
no sound
The test uses:
7.125:0009:trace:alsa:AUDDRV_GetAudioEndpoint "plughw:0,1" alsa:dump_fmt SubFormat: {00000003-0000-0010-8000-00aa00389b71}
Floating point is supported, so there should be audible sound on device plughw:0,1. What does speaker-test -D"plughw:0,1" do and report?
What the log doesn't tell is why "default" can't be opened. What if you use winecfg to select a non-default device? What if you set the new winealsa.drv input and output registry keys to "asnoop" and "amix"? (you don't need the duplex device since there are 2 keys.)
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #11 from Antonio López amlopezalonso@gmail.com 2012-02-27 14:44:20 CST --- (In reply to comment #10)
an empty render.log
2&>1 should have read 2>&1 as in comment #5 Also, prefer the pair rm render.log; .... >>render.log (use append mode, cf. bug #19125) The test results must appear together with the traces.
OK, please check the new render.log
no sound
The test uses:
7.125:0009:trace:alsa:AUDDRV_GetAudioEndpoint "plughw:0,1" alsa:dump_fmt SubFormat: {00000003-0000-0010-8000-00aa00389b71}
Floating point is supported, so there should be audible sound on device plughw:0,1. What does speaker-test -D"plughw:0,1" do and report?
It outputs no sound (but check the attached trace).
What the log doesn't tell is why "default" can't be opened. What if you use winecfg to select a non-default device?
All non-default devices output the same stuttering sound except the digital output that yields no sound.
What if you set the new winealsa.drv input and output registry keys to "asnoop" and "amix"? (you don't need the duplex device since there are 2 keys.)
I still have to try this which I'll do soon.
Regards, Antonio
http://bugs.winehq.org/show_bug.cgi?id=29294
Antonio López amlopezalonso@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #39046|0 |1 is obsolete| |
--- Comment #12 from Antonio López amlopezalonso@gmail.com 2012-02-27 14:46:44 CST --- Created attachment 39117 --> http://bugs.winehq.org/attachment.cgi?id=39117 new render.log
A clear beeping pattern (with no stuttering) can be heard.
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #13 from Antonio López amlopezalonso@gmail.com 2012-02-27 14:47:55 CST --- Created attachment 39118 --> http://bugs.winehq.org/attachment.cgi?id=39118 speaker-test -D"plughw:0,1" output
http://bugs.winehq.org/show_bug.cgi?id=29294
Robert Walker robert_mt_walker@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |robert_mt_walker@yahoo.co.u | |k
http://bugs.winehq.org/show_bug.cgi?id=29294
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #39118|application/octet-stream |text/plain mime type| |
http://bugs.winehq.org/show_bug.cgi?id=29294
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #39117|application/octet-stream |text/plain mime type| |
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #14 from Jörg Höhle hoehle@users.sourceforge.net 2012-02-28 06:06:46 CST ---
The test results must appear together with the traces.
Please ensure you get both into the log. Your newest one only contains test results, no trace from WINEDEBUG=+xyz. rm render.log; ENV=XY E=mc2 program args >>render.log 2>&1 Also, please set MIME-type text/plain manually on text attachments if your browser can't do it right.
All non-default devices output the same stuttering sound except the digital output that yields no sound. A clear beeping pattern (with no stuttering) can be heard.
I'm confused. When is it stuttering, when not? Please try to be as precise as possible.
What do you mean by default? I'm referring to a log trace like this:
AUDDRV_GetAudioEndpoint "default" 0x124928 0 0x32fb38
which shows that the ALSA device named "default" was opened. This is not necessarily the same as mmdevapi's default device, or winmm device #0.
render.c:1210: padding 24000 position 36096/48000 slept 750ms iteration 3 render.c:1244: data at (nil) (small 0) render.c:1246: Test failed: NULL buffer returned
Here the trace is important to figure out how exactly this device claimed to have a full buffer during 100ms.
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #15 from Antonio López amlopezalonso@gmail.com 2012-02-28 15:55:08 CST --- (In reply to comment #14)
The test results must appear together with the traces.
Please ensure you get both into the log. Your newest one only contains test results, no trace from WINEDEBUG=+xyz. rm render.log; ENV=XY E=mc2 program args >>render.log 2>&1
OK, let's try again... (see attachment).
All non-default devices output the same stuttering sound except the digital output that yields no sound. A clear beeping pattern (with no stuttering) can be heard.
I'm confused. When is it stuttering, when not? Please try to be as precise as possible.
Stuttering *is* present when running any sounding app after selecting any audio device (either labelled default or not) in winecfg (audio tab)...except the "...digital" entry which outputs no sound.
Stuttering is *not* present when running the render.log test (beeps are clearly audible with no apparent stutter).
What do you mean by default? I'm referring to a log trace like this:
AUDDRV_GetAudioEndpoint "default" 0x124928 0 0x32fb38
which shows that the ALSA device named "default" was opened. This is not necessarily the same as mmdevapi's default device, or winmm device #0.
I mean any device labelled as "default" in winecfg.
http://bugs.winehq.org/show_bug.cgi?id=29294
Antonio López amlopezalonso@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #39117|0 |1 is obsolete| |
--- Comment #16 from Antonio López amlopezalonso@gmail.com 2012-02-28 15:56:55 CST --- Created attachment 39132 --> http://bugs.winehq.org/attachment.cgi?id=39132 render.log test including trace
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #17 from Jörg Höhle hoehle@users.sourceforge.net 2012-02-29 03:27:37 CST ---
I mean any device labelled as "default" in winecfg.
Alas, this is not precise enough. The only definite answer is: 7.164:0009:trace:alsa:AUDDRV_GetAudioEndpoint "default" The reason is that wine will normally scan ALSA devices and make default in winecfg the first device that it finds working.
For unknown reasons, your latest log is radically different from the former one: 0.734:warn:alsa:alsa_try_open The device "plughw:0,0" failed to open: -16 (Dispositivo o recurso ocupado). 0.742:warn:alsa:alsa_try_open The device "plughw:0,0" failed to open: -16 (Dispositivo o recurso ocupado). 0.749:trace:alsa:AUDDRV_GetAudioEndpoint "default" 0x1248a0 0 0x32fb38 Compare this with comment #8
The key difference is that in the former run, ALSA "default" was occupado, hence Wine used "plughw:0,1" as default, which produced no sound on your machine IIRC (perhaps it's the digital output?). In your latest log, ALSA's "default" opens successfully, so Wine uses that as its own default. As it happens, it plays sound well.
It would be good if you could find out what caused that difference. It should be systematic, not random.
Stuttering *is* present when running any sounding app Stuttering is *not* present when running the render.log test
It may not look like so, but now we've made a lot of progress. You now must try and split your apps in 3 categories: 1. old ones that use winmm for sound (or intros); 2. ones that use DSound; 3. modern ones running in w7 mode that use mmdevapi directly. Use WINEDEBUG=+loaddll to see what gets loaded. Category 3 should play well, because they typically use XAudio2 and the render test is believed to behave like XAudio2. I believe winmm would work well on your machine too. DSound->mmdevapi may have its own quirks. If only DSound is problematic, this issue may end up as a duplicate of bug #28781 or some other DSound stuttering bug, independent on Jack/loopback.
I encourage you to export WINETEST_INTERACTIVE=1 cd dlls/winmm/tests; rm *.ok; make wave.ok mci.ok cd dlls/dsound/tests; rm *.ok; make test and hear how the sine tests perform. Be aware that the 24/32 bit tests produce awful sounds instead of sines. You may want to uncomment them.
21.229:mmdevapi:MMDevice_Destroy Freeing L"Conexant CX8811 - CX88 Digital" 21.229:mmdevapi:MMDevice_Destroy Freeing L"Loopback - Loopback PCM" 21.229:mmdevapi:MMDevice_Destroy Freeing L"HDA VIA VT82xx - ALC660 Digital" 21.229:mmdevapi:MMDevice_Destroy Freeing L"Loopback - Loopback PCM"
Andrew, it's no good that the names solely appear at Release time in the logs last lines and without connection to the corresponding device id.
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #18 from Antonio López amlopezalonso@gmail.com 2012-02-29 18:14:30 CST --- (In reply to comment #17)
The key difference is that in the former run, ALSA "default" was occupado, hence Wine used "plughw:0,1" as default, which produced no sound on your machine IIRC (perhaps it's the digital output?). In your latest log, ALSA's "default" opens successfully, so Wine uses that as its own default. As it happens, it plays sound well.
It would be good if you could find out what caused that difference. It should be systematic, not random.
I'll try to work it out.
It may not look like so, but now we've made a lot of progress. You now must try and split your apps in 3 categories:
- old ones that use winmm for sound (or intros);
- ones that use DSound;
- modern ones running in w7 mode that use mmdevapi directly.
Use WINEDEBUG=+loaddll to see what gets loaded. Category 3 should play well, because they typically use XAudio2 and the render test is believed to behave like XAudio2. I believe winmm would work well on your machine too. DSound->mmdevapi may have its own quirks. If only DSound is problematic, this issue may end up as a duplicate of bug #28781 or some other DSound stuttering bug, independent on Jack/loopback.
For test purposes I chose Silent Hunter 4, set winecfg to Windows 7 and logged the results (check new attachment). The sound was still stuttering and I was unable to tell which dll was being effectively used as it seemed to me that all three sound dlls (dsound, winmm and mmdevapi) were being loaded.
I encourage you to export WINETEST_INTERACTIVE=1 cd dlls/winmm/tests; rm *.ok; make wave.ok mci.ok cd dlls/dsound/tests; rm *.ok; make test and hear how the sine tests perform. Be aware that the 24/32 bit tests produce awful sounds instead of sines. You may want to uncomment them.
No sound from these tests as plughw:0,0 is being used.
What if you set the new winealsa.drv input and output registry keys to "asnoop" and "amix"? (you don't need the duplex device since there are 2 keys.)
It still stutters (set ALSAInputDevices and ALSAOutputDevices to asnoop and amix respectively).
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #19 from Antonio López amlopezalonso@gmail.com 2012-02-29 18:16:55 CST --- Created attachment 39141 --> http://bugs.winehq.org/attachment.cgi?id=39141 SH4 audio log (WINEDEBUG=+loaddll,+alsa,+tid,+timestamp,+mmdevapi,+dsound,+winmm)
http://bugs.winehq.org/show_bug.cgi?id=29294
Antonio López amlopezalonso@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #39141|0 |1 is obsolete| |
--- Comment #20 from Antonio López amlopezalonso@gmail.com 2012-02-29 18:18:40 CST --- Created attachment 39142 --> http://bugs.winehq.org/attachment.cgi?id=39142 SH4 audio log (WINEDEBUG=+loaddll,+alsa,+tid,+timestamp,+mmdevapi,+dsound,+winmm)
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #21 from Jörg Höhle hoehle@users.sourceforge.net 2012-03-01 16:50:15 CST ---
No sound from these tests as plughw:0,0 is being used.
Please investigate further. winmm:wave iterates across all winmm devices, so it should use all devices that mmdevapi could open, likely not solely plughw:0,0.
Then I'd like you to run the render+winmm+dsound tests N times, every time with a different audio device selected via winecfg. Verify in the log that mmdevapi's default device changes. This is the one that gets used to produce the sine wave in the render test. You now know how to use the log's AUDDRV_GetAudioEndpoint lines to verify what gets used (search for the last occurrence in the file). What differences can you observe or hear?
35.166:0009:trace:dsound:DirectSoundDevice_Create 35.166:0009:trace:dsound:DSOUND_ReopenDevice 35.166:0009:trace:alsa:AUDDRV_GetAudioEndpoint "default"
SH4 uses DSound.
alsa:dump_fmt nSamplesPerSec: 44100 alsa:AudioClient_Initialize ALSA period: 5512 frames alsa:AudioClient_Initialize ALSA buffer: 16537 frames alsa:AudioClient_Initialize MMDevice period: 441 frames alsa:AudioClient_Initialize MMDevice buffer: 5120 frames
Winealsa is in trouble because its buffer is smaller than ALSA's period! This is almost a guarantee for underruns.
I now see that was already present in the render log:
alsa:dump_fmt nSamplesPerSec: 48000 alsa:AudioClient_Initialize ALSA period: 6000 frames alsa:AudioClient_Initialize ALSA buffer: 18000 frames alsa:AudioClient_Initialize MMDevice period: 480 frames alsa:AudioClient_Initialize MMDevice buffer: 2400 frames
But there our lead-in prevented an underrun (as it was designed to do) in the test_worst_case XAudio2 scenario:
alsa:alsa_write_data lead-in 6192
with SH4 and DSound, the lead-in is much smaller due to DSound's own prefill: alsa:alsa_write_data lead-in 1009
These are the issues: - Huge ALSA period. Absence of stutter in the mmdevapi:render test proves that the situation is not as unbearable as it seems. Probably we can continue to pretend to operate with 10ms periods known from mmdevapi (and DSound), instead of switching to ALSA's 125ms period. Yet it's a bit hairy.
- CreateTimerQueueTimer, known from bug #28723, comment #130, kicks in at about 11ms only. That's not enough. Because of that, ALSA padding slowly decreases from 6288 (more than one ALSA period) to 3600 (a half period) while playing 1 second. If you would change the render test to play for 1 minute, it would hit an underrun. Can you increase the number of iterations (i<5999) in dlls/mmdevapi/tests/render.c:2102 and recompile to check that?
- DSound. It doesn't yet use GetCurrentPadding and GetPosition like I believe it should. Actually, I believe it should implement a behaviour not unlike XAudio2(!)... Again, how do the dlls/dsound/tests sound? The log shows that DSound lets padding decrease from ~6000 to ~4000. If it were doing its job well, padding would remain roughly constant.
- Delays from ALSA 41.535:0027:trace:alsa:alsa_write_data pad: 0 41.555:0027:trace:alsa:alsa_write_data lead-in 1009 Why did 20ms elapse upon start? Perhaps ALSA needs that much time to set up processing.
- Out of the blue underruns 41.667:0027:trace:alsa:alsa_write_data pad: 4439 41.674:0028:trace:alsa:AudioClock_GetPosition frames written: 8704, held: 0, avail: 11939, delay: 4598 state 3, pos: 4106 41.677:0027:trace:alsa:alsa_write_data pad: 4421 41.684:0028:trace:alsa:AudioClock_GetPosition frames written: 9216, held: 0, avail: 11956, delay: 4581 state 4, pos: 9216
ALSA has 100ms of data, yet it will signal an underrun. Surprisingly, the underruns are periodic and 130-140ms apart, which is close to the period size. Oddly, you said the render test played fine and they happen to have even fewer frames left in the ALSA buffer. Perhaps the different frame rate makes a difference? Please retry SH4 after setting DefaultSampleRate to 48000 for DSound in the registry. Check in the log that 48000 gets used then.
Perhaps underruns would not happen if ALSA always had a full period? The lead-in was designed to satisfy that property, but it still requires CreateTimerQueue or DSound to refill data fast enough.
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #22 from Andrew Eikum aeikum@codeweavers.com 2012-03-02 07:53:52 CST --- (In reply to comment #21)
- DSound. It doesn't yet use GetCurrentPadding and GetPosition like I believe
it should.
I actually have a patchset which accomplishes this, built on top of the resampler stuff from Bug 14717. I would like to think about it for a few more days before making it public, though.
http://bugs.winehq.org/show_bug.cgi?id=29294
James Hudson xtroce@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |xtroce@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #23 from James Hudson xtroce@gmail.com 2012-03-06 19:57:44 CST --- Created attachment 39217 --> http://bugs.winehq.org/attachment.cgi?id=39217 civ stuttering default
tbz of stuttering with default configuration and WINEDEBUG=+loaddll,+alsa,+tid,+timestamp,+mmdevapi,+dsound,+winmm
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #24 from James Hudson xtroce@gmail.com 2012-03-06 19:59:55 CST --- Created attachment 39218 --> http://bugs.winehq.org/attachment.cgi?id=39218 civ stuttering dsound bitrate 44800
civ5 stuttering with dsound default bitrate 44800 and WINEDEBUG=+loaddll,+alsa,+tid,+timestamp,+mmdevapi,+dsound,+winmm
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #25 from James Hudson xtroce@gmail.com 2012-03-06 20:10:04 CST --- Hi, i got the same comment with Civ 5 and the alsa loopback device through jack. I used the same configuration as Antoniofor that matter. I attached the logs of civ5 starting with the default configuration, and one with civ5 started with the regkey for dsound's default bitrate at 44800. stuttering is still there with the bitrate changed. I didn't run the tests yet but will do so as soon as i can find the time. What also occurred was that the stuttering got worse the longer the program an and then totally stopped after a minute or so. this is captured in the default log attached. I also tried to switch jackd's sample rate to 44100 but i think this is kind of pointless, as the problem is in the alsa part as far as i understood the discussion., nm for the completeness here's my jack configuration: -T -ndefault -v -r -dalsa -dhw:1 -r48000 -p1024 -n2 wine used hw:0 as it should, for this is the loopback device. so the config as you can see is no-realtime 48000 samplerate and 1024 frames, with 2 periods.
http://bugs.winehq.org/show_bug.cgi?id=29294
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|1.4.0 |1.6.0
--- Comment #26 from Austin English austinenglish@gmail.com 2012-03-07 13:27:22 CST --- Moving milestone to 1.6.
http://bugs.winehq.org/show_bug.cgi?id=29294
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|1.6.0 |1.4.0
--- Comment #27 from Austin English austinenglish@gmail.com 2012-03-07 13:34:36 CST --- My mistake, 1.6 criteria are not set yet, so these need to stay in 1.4.
Sorry for the noise.
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #28 from Jörg Höhle hoehle@users.sourceforge.net 2012-03-07 15:26:59 CST --- James, multi-MB logs from a closed source app are not as helpful to me as logs produced by the Wine tests where everybody can look at the source and see what the test app does. I saw nothing in the log that wasn't mentioned in comment #21 already, e.g. repeated "out of the blue underruns" 120-140ms apart, with padding around 4000 frames, CreateTimerQueue slew and DSound letting padding slowly decrease. IOW, you system acts like Antonio's.
What would help me is to systematically perform the tests mentioned in comment #17 and comment #21. Do the WINETEST_INTERACTIVE render tests produce good output? The winmm ones? The dsound ones? Additionally, what if you increase EXTRA_SAFE_RT to 300000 (30ms) in dlls/winealsa.drv/mmdevdrv.c or even beyond that value?
It seems that your logs were not generated using the >> append-mode trick mentioned above, were they? Some lines are simply missing, or something odd is going on with Wine's logging. E.g. where's the line about "pad:" or "XRun" that must precede:
27.015:0050:trace:alsa:alsa_write_data lead-in 1009
It cannot be:
27.005:0050:trace:alsa:alsa_write_data pad: 3954
because thread 005c managed to grab the device's critical section in-between.
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #29 from Andrew Eikum aeikum@codeweavers.com 2012-03-08 13:30:07 CST --- The maintainer of KXStudio posted an asoundrc and alsa_in daemon script on the Sound wiki page. He's able to play audio in Wine without problems using his setup. Users having trouble here might find it worth trying his setup and reporting back here: http://wiki.winehq.org/Sound
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #30 from Antonio López amlopezalonso@gmail.com 2012-03-08 18:28:04 CST --- (In reply to comment #21)
No sound from these tests as plughw:0,0 is being used.
Please investigate further. winmm:wave iterates across all winmm devices, so it should use all devices that mmdevapi could open, likely not solely plughw:0,0.
Then I'd like you to run the render+winmm+dsound tests N times, every time with a different audio device selected via winecfg. Verify in the log that mmdevapi's default device changes. This is the one that gets used to produce the sine wave in the render test. You now know how to use the log's AUDDRV_GetAudioEndpoint lines to verify what gets used (search for the last occurrence in the file). What differences can you observe or hear?
Whatever device I choose I get stuttering plus the last GetAudioEndpoint always set to "default".
- CreateTimerQueueTimer, known from bug #28723, comment #130, kicks in at about
11ms only. That's not enough. Because of that, ALSA padding slowly decreases from 6288 (more than one ALSA period) to 3600 (a half period) while playing 1 second. If you would change the render test to play for 1 minute, it would hit an underrun. Can you increase the number of iterations (i<5999) in dlls/mmdevapi/tests/render.c:2102 and recompile to check that?
See the results in the attachment.
Still have to try DefaultSampleRate to 48000.
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #31 from Antonio López amlopezalonso@gmail.com 2012-03-08 18:28:57 CST --- Created attachment 39254 --> http://bugs.winehq.org/attachment.cgi?id=39254 Render test after setting render.c loop to 1 min.
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #32 from Jörg Höhle hoehle@users.sourceforge.net 2012-03-09 07:57:41 CST ---
I saw nothing in the log
James, on a second thought, I found an issue sufficiently important to warrant its own report: bug #30118 is about sound stopping after: 62.190:alsa_write_best_effort writei failed, recovering: -32 (Broken pipe)
BTW, 44800 is nothing standard. Did you mean 48000?
Antonio, please make sure your logs always include both test results like: render.c:945: Clock Frequency 48000 as well as the traces like: 41.667:0027:trace:alsa:alsa_write_data pad: 4439 using the >>render.log 2>&1 trick. Your latest log solely contains the former and it's impossible to tell what caused: render.c:1243: Test failed: NULL buffer returned
I get stuttering plus the last GetAudioEndpoint always set to "default".
That means wine did not manage to open the other devices. For instance, something like hw:0 will be unavailable while jackd grabs it. However, "amix" should have worked via ALSAOutputDevices in the registry.
comment #15 >Stuttering is *not* present when running the render.log comment #30>Whatever device I choose I get stuttering Now you lost me. What's the difference between those two test runs of mmdevapi:render?
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #33 from James Hudson xtroce@gmail.com 2012-03-09 10:30:53 CST --- Created attachment 39269 --> http://bugs.winehq.org/attachment.cgi?id=39269 dsound test
dsound test log as far as i can tell the sound output worked fine
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #34 from James Hudson xtroce@gmail.com 2012-03-09 10:32:53 CST --- Created attachment 39270 --> http://bugs.winehq.org/attachment.cgi?id=39270 default configuration render test
the default render test created with:
WINETEST_INTERACTIVE=1 WINETEST_DEBUG=2 WINEDEBUG=+alsa,+tid,+timestamp,+mmdevapi make render.ok >> /tmp/render.log 2>&1
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #35 from James Hudson xtroce@gmail.com 2012-03-09 10:40:21 CST --- Created attachment 39272 --> http://bugs.winehq.org/attachment.cgi?id=39272 render test with 5999 iterations
the render test with increased iterations created with: WINETEST_INTERACTIVE=1 WINETEST_DEBUG=2 WINEDEBUG=+alsa,+tid,+timestamp,+mmdevapi make render.ok >> /tmp/render.log 2>&1
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #36 from James Hudson xtroce@gmail.com 2012-03-09 10:55:34 CST --- Created attachment 39273 --> http://bugs.winehq.org/attachment.cgi?id=39273 winmm test log
the winmm test log made with: make wave.ok mci.ok >> winmm.log 2>&1 sound was ok, clear pattern, otherwise no sound at the second and third round, with (1) and (2) after the function name. dont' know if this should be...
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #37 from James Hudson xtroce@gmail.com 2012-03-09 11:53:47 CST --- @joerg: one more thing: i just tested the sound with vlc and the stuttering is also present there. if it helps i can get a log with that, so you have a opensource project with the error. i'm just not sure if vlc has the debug symbols activated. i installed it with winetricks btw.
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #38 from Jörg Höhle hoehle@users.sourceforge.net 2012-03-09 12:16:00 CST --- James, what was the sound experience while running the tests? Judging from the render log, I'd say: - no stuttering, however - one underrun every 5 seconds from clock skew. The CreateTimerQueue stabilisator patch will help here (but not eliminate it entirely). That causes an audible glitch every time.
Every underrun costs 50ms or more, for unknown reason. It also explains the occasional Wait() failure: 2307.448:trace:alsa:alsa_write_data pad: 480 render.c:2104: Test failed: Wait iteration 3233 gave 102 2307.518:warn:alsa:alsa_write_best_effort writei failed, recovering: -32 (Broken pipe) ALSA lib pcm.c:7316:(snd_pcm_recover) underrun occurred 2307.518:trace:alsa:alsa_write_data pad: 432
- A few alsa_write_best_effort writei failed However, unlike bug #30118, much to my surprise, the device keeps running. So another underrun is signaled a little later, this time causing a lead-in to be written. Then audio restarts for another 5 seconds. 2406.776:trace:alsa:alsa_write_data pad: 48 2406.776:warn:alsa:alsa_write_best_effort writei failed, recovering: -32 (Broken pipe) ALSA lib pcm.c:7316:(snd_pcm_recover) underrun occurred 2406.778:trace:alsa:AudioClient_GetCurrentPadding (0x12b0a8)->(0x32fbe8) [...] 2406.796:trace:alsa:alsa_write_data pad: 48 [...] 2406.800:trace:alsa:AudioRenderClient_ReleaseBuffer (0x12b0a8)->(480, 0) 2406.806:trace:alsa:alsa_write_data XRun state avail 18000, recovering 2406.807:trace:alsa:alsa_write_data lead-in 6192
I don't know how to explain the difference in behaviour. Maybe it's solely a bad interaction with DSound, after all. Please try out Andrew Eikum's patches attached to bug #30118.
- The occasional GetBuffer(NULL) test failure is somewhat caused by a limitation of the winealsa driver. We need another design to mimic native's regular decrease of padding when facing huge ALSA periods like 125ms. Here mmdevapi's buffer is full, ALSA is over 2/3 full, so mmdevapi will not write more frames.
Does VLC use DSound for output? Would it use mmdevapi directly if you switched winecfg to w7 mode?
http://bugs.winehq.org/show_bug.cgi?id=29294
Lucas Fialho Zawacki lfzawacki@yahoo.com.br changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lfzawacki@yahoo.com.br
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #39 from James Hudson xtroce@gmail.com 2012-03-09 13:01:42 CST --- ok, i checked vlc and it uses dsound, even when switching to win7. but what i found out was that if you use winetricks to make an overwrite on dsound.dll and use the dx9 one instead of the wine version the extreme stuttering goes away and there are just minor cracks in the sound. still not perfect but at least you can understand everything. I will install the patch you mentioned and try again. Furthermore i'll try to find a prog that uses mmdevapi and test if the problem is present there.
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #40 from James Hudson xtroce@gmail.com 2012-03-09 14:39:34 CST --- ok, followup. i've installed the patchset and you have roughly the same experience as with the original dsound.dll. Sound works much better, less stuttering but still present. the sound in civ doesn't crash after a minute but it still is stuttering roughly 2-4 times a second. The video in vlc had no problem with the sound except for running asynchronous but thats something different i think. Otherwise my guess from listening experience would be that it is linked to multiple sounds that are played toegther now, if that makes any sense. Should I put toghether another log with the patch installed?
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #41 from Jörg Höhle hoehle@users.sourceforge.net 2012-03-11 12:10:36 CDT --- Let's focus on something or we'll reach comment number 100 and still mix lots of different issues. The initial comment #0 was about no sound at all and winecfg. So let's decide this issue is not about Jack + DSound but about Jack + the lower-level mmdevapi and optionally winmm (which winecfg uses).
Regarding DSound with Jack, I think it's justified to create a bug report distinct from bug #30118. Jack's 125ms period is sufficiently different from the ones used by plughw:0, plug:dmix or PA to merit special attention.
System construction is important to me. If the lowest level SW-layer has bugs, how can you expect the higher levels to work properly? That's why I want good sound from mmdevapi first, before paying attention to issues with DSound. See comment #17. Winmm is much less complex than DSound, so at this point in time, it's ok to look at Jack + winmm.
So for this bug report, I'd appreciate from both of you a summary of the current situation regarding mmdevapi and winmm, disregarding DSound. Based on what you reported, it looks as follows to me. Please correct:
+ There is sound and winecfg's test sound works. + WINETEST_INTERACTIVE=1 produces an audible sine wave sound during both the mmdevapi and winmm tests. - The mmdevapi tests may be crackling or have some drop-outs, i.e. short periods of silence when it should play continuously for one second. + Crackling from the mmdevapi tests is much reduced with my ntdll CreateTimerQueue stabilisator patch. - Because of clock skew, it's not eliminated completely. - render.c:1243: Test failed: NULL buffer returned That occasional failure is explained by winealsa's 3x period size filler algorithm in the presence of the huge 125ms ALSA period. The ALSA buffer is >2/3 full for over 100ms such that winealsa will not write more frames to it, hence padding does not decrease. This is not nice, but should be harmless in practice.
Antonio and James use the same Jack yet it seems like Antonio hears more stuttering at the basic tests? What do you believe?
What about: ? the sine wave from the winmm tests? Perfect? ? What if you use much longer playing times in the winmm:wave test? In wave_out_test_deviceOut add duration *= 20; ? How well does winmm play sound? Please follow my instructions at bug #27937, comment #0 and test a long-playing .wav sound using the MCI shell. ? How often does crackling repeat in the mmdevapi tests with the patch applied? The logs analysed in comment #38 showed it occurs every 5 seconds without the patch. Please increase the duration of the sine test and report back. ? How do the sine waves sound if you hack the tests to play at a rate other than 48000fps?
You might argue that using native's DSound is like using Wine's winmm. "Sound works much better [...] but it still is stuttering roughly 2-4 times a second." We'll look at native DSound after Wine's mmdevapi and winmm work fine. "The video in vlc [...] running asynchronous" you mean loss of lip synchronisation? That's would be an issue with GetPosition that we'll look at later.
otherwise no sound at the second and third round, with (1) and (2) after the function name
waveOutGetPosition(2) means Wine found 3 audio devices. It numbers them 0, 1 and 2. If you use runtest without -q, the wave test will show the ALSA device names. WAVE_MAPPER is a virtual device that adds codecs or resampling on top of another device, typically number 0.
http://bugs.winehq.org/show_bug.cgi?id=29294
Alex Bradbury asb@asbradbury.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |asb@asbradbury.org
--- Comment #42 from Alex Bradbury asb@asbradbury.org 2012-03-12 07:14:18 CDT --- (In reply to comment #29)
The maintainer of KXStudio posted an asoundrc and alsa_in daemon script on the Sound wiki page. He's able to play audio in Wine without problems using his setup. Users having trouble here might find it worth trying his setup and reporting back here: http://wiki.winehq.org/Sound
There seems to be some disagreement as to where those instructions should go, so for now find it here: http://wiki.winehq.org/Sound?rev=50
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #43 from James Hudson xtroce@gmail.com 2012-03-12 12:54:02 CDT --- (In reply to comment #42)
(In reply to comment #29)
The maintainer of KXStudio posted an asoundrc and alsa_in daemon script on the Sound wiki page. He's able to play audio in Wine without problems using his setup. Users having trouble here might find it worth trying his setup and reporting back here: http://wiki.winehq.org/Sound
There seems to be some disagreement as to where those instructions should go, so for now find it here: http://wiki.winehq.org/Sound?rev=50
ok i tried this setup and with this configuration + jack2 and realtime sound works without flaws
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #44 from Jörg Höhle hoehle@users.sourceforge.net 2012-03-12 13:07:49 CDT ---
with this configuration + jack2 and realtime sound works without flaws
Why? What's different? Why does adding an extra coupling process in the WineALSA - alsa_in/out - Jack chain help? What's the hidden cost? Please attach the usual DEBUG+>>render.log so we get a chance to see.
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #45 from James Hudson xtroce@gmail.com 2012-03-12 14:48:17 CDT --- (In reply to comment #44)
with this configuration + jack2 and realtime sound works without flaws
Why? What's different? Why does adding an extra coupling process in the WineALSA - alsa_in/out - Jack chain help? What's the hidden cost? Please attach the usual DEBUG+>>render.log so we get a chance to see.
i still have to run the tests but what i changed where the extra configurations for the dmix and dsnoop devices of the loop and the dsnoop at the hw1 end
this was what i added:
ipc_key_add_uid true slave { pcm "hw:Loopback,0,0" format S32_LE rate { @func igetenv vars [ JACK_SAMPLE_RATE ] default 44100 } period_size { @func igetenv vars [ JACK_PERIOD_SIZE ] default 1024 } buffer_size 4096
furthermore i used jack 1.9.8 instead of 0.121.3
as soon as i'm done with the test i'll upload the log, do you need it with the longer period or first the standard one?
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #46 from Antonio López amlopezalonso@gmail.com 2012-03-12 15:51:17 CDT --- Be aware that the second method requires using JACK2 and that ALSA sound will fail if the former is not running while the first loopback method is JACK1-based and also is a failure-proof one. I must note this issue as they seem to be quite different approaches.
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #47 from James Hudson xtroce@gmail.com 2012-03-13 12:27:52 CDT --- ok, after some more testing, first i tested if the working version had to do with realtime, but it also worked without (just tested to be sure) furthermore i installed jack1 again restarted the whole process and tested with exactly the same configuration that gave me the stuttering except for the .asoundrc with the changes mentioned above. And still no stuttering in the audio. The only thing i realized after testing it for a while was that it doesn't run synchronous. So in Civ with the working sound, the click sound comes roughly 1/2 second afer it should play. I rebuild wine git and did the render test again. i also used jack_capture to record my audio experience with the testso you can compare the audio experience i hhad with the one you get.
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #48 from James Hudson xtroce@gmail.com 2012-03-13 12:29:06 CDT --- Created attachment 39339 --> http://bugs.winehq.org/attachment.cgi?id=39339 the log of the working sound
standard render test with the new .asoundrc and no stuttering in the apps
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #49 from James Hudson xtroce@gmail.com 2012-03-13 12:43:43 CDT --- Created attachment 39340 --> http://bugs.winehq.org/attachment.cgi?id=39340 audio experience with the render test
ogg of the two channels of what the test sounds like
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #50 from James Hudson xtroce@gmail.com 2012-03-13 12:46:59 CDT --- oh i just realized that downloading the git again removed the cleanup patches. but my system still got them installed for the wine version i used to test with civ. I shuold install them recompile and then upload the test results again, sry
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #51 from James Hudson xtroce@gmail.com 2012-03-13 12:54:09 CDT --- (In reply to comment #50)
oh i just realized that downloading the git again removed the cleanup patches. but my system still got them installed for the wine version i used to test with civ. I shuold install them recompile and then upload the test results again, sry
not my day today ^^ the patch shouldn't matter because it's dsound and the render test has nothing to do with it, right?
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #52 from Jörg Höhle hoehle@users.sourceforge.net 2012-03-13 18:58:46 CDT --- I don't know which of the several patch sets floating around you mean: - ntdll CreateTimerQueue rate stabilisator -- essential - lock-less winealsa -- nice to have, needs ntdll patch - dsound resampler -- good for games - dsound GetPosition/GetCurrentPadding clean up -- dito
Follows the analysis of your latest log. By using runtest -q the test traces are omitted. Please do not use -q
The preferred 1024 frames / 44100 rate from comment #45 is visible in the log. The resulting period is ~23ms, very small and close to mmdevapi's preferred 10ms. That explains the absence of underruns. Also, the underlying device appears to be something like plug (incl. resampler) which explains a very regular increase of position from snd_pcm_delay. So from Wine's POV, everything is fine.
HOWEVER, as you've noticed, the overall latency is huge. That's not what you installed Jack for. The reason simply is the extra pass-through process. Due to the decoupling, the latency reported by ALSA to Wine (~90ms) is only part of the chain and missing everything that follows, e.g. what that pass-through buffers or what the alsa_in and alsa_out add. That extra process broke Jack's control loop.
Looking at the .asoundrc example from the document you linked, I suggest you play with the period_size.
# Don't use a buffer size that is too small. Some apps # won't like it and it will sound crappy
That comment does not apply to Wine. Quite to the contrary, the 4096 period size ~100ms causes trouble. Prefer at most half that size. Furthermore, mmdevapi's preferred rate is 48000 so you should not use 44100. (DSound has its own preferred (settable) rate different from mmdevapi...)
In summary, try to play with the period size in your .asoundrc. Remember that Wine got a 125ms period (comment #21) that it doesn't handle well.
alsa:AudioClient_Initialize ALSA period: 6000 frames
Find some amix settings such that it is much reduced.
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #53 from Antonio López amlopezalonso@gmail.com 2013-02-17 14:45:18 CST --- A bit off-topic but I noticed this issue also (and only besides Wine) happens with "native" Linux games like Unigine's Oil Rush and Steam stuff (Serious Sam 3, at least). Are these truly native ports or are in-the-hood, Wine-based ports? Just curious about it...
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #54 from kisak42@gmail.com 2013-02-17 21:01:54 CST --- For what it's worth, since I confirmed I had this issue, the condition of wine with the alsa loopback device on my system has improved to the point I no longer have an issue. There has been various tweaks to config files to mitigate the symptoms and the mmdevapi core has matured over time.
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #55 from Antonio López amlopezalonso@gmail.com 2013-02-18 02:28:39 CST --- (In reply to comment #54)
There has been various tweaks to config files to mitigate the symptoms and the mmdevapi core has matured over time.
Could you please detail those tweaks for me? For I haven't experienced any improvement yet in this matter... :-(
You may want to reply to my email to avoid too much off-topic noise...
Regards, Antonio
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #56 from Antonio López amlopezalonso@gmail.com 2013-02-22 09:39:34 CST --- I moved into the setup described in:
http://wiki.winehq.org/Sound?rev=50
and sound works ok now (I get Qjackctl icon frozen though but that's a minor issue).
http://bugs.winehq.org/show_bug.cgi?id=29294
--- Comment #57 from Jörg Höhle hoehle@users.sourceforge.net 2013-03-04 15:22:10 CST --- It's good that you found a working setup. Yet I tend to consider this extra Python middleware process a hack which is why I'd like to see logs from current wine, perhaps produced under both configurations: the naïve alsa_jack bridge and then the working setup.
cd dlls/mmdevapi/tests; rm /tmp/render.log; WINETEST_INTERACTIVE=1 WINETEST_DEBUG=2 WINEDEBUG=+tid,+timestamp,+alsa,+mmdevapi wine mmdevapi_test.exe render >>/tmp/render.log 2>&1
Does the sine wave sound good? What about comment #47, "So in Civ with the working sound, the click sound comes roughly 1/2 second afer it should play." Is that still the case or does "sound works ok now" in comment #56 mean that there's no such huge latency?
If you don't compile Wine yourself, you can obtain mmdevapi.exe either from testbot http://testbot.winehq.org/JobDetails.pl?Key=24482 until expired or from the daily test.winehq.org winetest.exe which is a sort of self-executing archive that'll extract all tests when invoked with /x IIRC, then run the mmdevapi one.
https://bugs.winehq.org/show_bug.cgi?id=29294
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |ABANDONED
--- Comment #58 from Austin English austinenglish@gmail.com --- Abandoned.
https://bugs.winehq.org/show_bug.cgi?id=29294
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #59 from Austin English austinenglish@gmail.com --- Closing.
-
wine-bugs＠winehq.org