[pulseaudio-discuss] Moving sources and sinks

[Tomas Carnecky]

Nikolai Beier wrote:
> 2008/5/4 Tomas Carnecky <tom at dbservice.com>:
>> Nikolai Beier wrote:
>>  > Perhaps Winealsa (the output driver for ALSA) needs direct hardware
>>  > access? Or it is/was just coded that way, but does not need to be. Or
>>  > it was never a problem?
>>
>>  Wine should not need hardware access. Maybe it mistakenly did in the
>>  past. But it should not. If it still does, then it needs to be fixed.
> 
> So you know that the talk about DirectSound _needs_ hardware access,
> and cannot be emulated in a sensible and efficient way is wrong?
> Oh, it seems that Microsoft has produces an "DirectSound emulator"
> (meaning that the sound is send from DirectSound to a software mixer
> and the to the device driver) for Vista, so it should only be a
> question about latency to make wine get DirectSound go to a virtual
> ALSA interface, i.e. the ALSA device named "pulse".

The DirectSound DLL uses a special interface of the low-level sound 
driver. If that is not available it falls back to software emulation. 
This is the same for the original Windows DLL as well as the one shipped 
with Wine. So you have these two situations in Wine:

Software emulation:
  - DirectSound -> WinMM WaveOut functions -> alsa
DirectSound acceleration:
  - DirectSound -> special DirectSound interface -> alsa

The special DirectSound interface allows the DirectSound DLL to access 
alsa directly. Going through the WinMM WaveOut functions adds an 
additional layer, and therefore delay and CPU consumption. But last I 
checked the Wine alsa driver didn't use hardware mixing capabilities of 
the sound card, not when using the special DirectSound interface. So you 
have no real hardware acceleration, it's always mixing sound in software.

You see that DirectSound is using the alsa API in any case. On my 
desktop I configured alsa to use the pulse plugin. And therefore 
DirectSound is going through PA. The additional delay is barely noticeable.

>>  > * "wereHamster" noted that the ALSA pulse plugin might set Wine in an
>>  > endless loop. http://www.pulseaudio.org/ticket/198#comment:8
>>
>>  FYI, I'm wereHamster. I have a fix for that. I'll submit the patch after
>>  I figure out how to use mercurial.
> 
> So it is still a problem that can occur, and triggered by something
> else than the problem below?

There are currently two bugs in the alsa pulse plugin I know of. One 
affects Wine directly, the other is triggered by speaker-test.

>>
>>  > * Some have notices large delays (like one second), which is tracked
>>  > back to some delay calculations in the ALSA pulse plugin.
>>
>>  I haven't come across this problem. Are there bug reports that track
>>  this issue?
> Only your own: http://bugs.winehq.org/show_bug.cgi?id=10910#c8
> (mentioned previous in this email thread)
> I thought it was the same bug that your fix for pulse_dealy() should
> remove. We may have confused each other

That probably was an old test I did there. I tested today and I haven't 
seen any audible delay compared to using alsa/dmix directly.

The patch to pulse_delay() does not aim at decreasing delay, it only 
fixes one of the bugs.

> I hope you get the feedback on your patches that you want/need. E.g. the line
> delay = snd_pcm_bytes_to_frames(ti->write_index-ti->read_index) - 3000
> 
> I have not seen that c file that line belongs to, nor did I understand
> why 3000 was the magic number, and not random symptom treatment.
> Does "the thing" fail when delay is too big?
> If snd_pcm_bytes_to_frames() can return values below 3000, does the
> rest of alsa-pulse and Wine work as it should when delay gets a
> negative number?

It was symptom treatment. I just tested some random values until the 
Wine test didn't fail anymore. It's not needed anymore. I removed it 
from my local patch.

tom