[Bug 29294] No sound with ALSA loopback devices

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

--- Comment #41 from Jörg Höhle  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.