[pulseaudio-discuss] Moving sources and sinks

[Tomas Carnecky]

Colin Guthrie wrote:
> Tomas Carnecky wrote:
>> Colin Guthrie wrote:
>>> What are the bugs in the pulse alsa plugin you refer to? There are some
>>> feature limitations but they are typically down to what any ioplug
>>> plugin is capable of.
>> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2601 (see the 
>> comments made by wereHamster, that's me).
>>
>> http://pulseaudio.org/ticket/198
> 
> To be honest I thought all of the patches on that bug were now in alsa
> repo.... their bugtracker is such a pain to work with, it's like trying
> to find a needle in a haystack :(
 >
> All the recent comments were talking about speaker-test being at fault.
> I didn't realise there was still some issues with the actual alsa-plugin
> end. I guess I'll try and read through it again with a strong cup of
> coffee and see if I can understand it again. Not that I'd be able to do
> much about it.... but I would like to appreciate what is going on :)
> 
> FWIW, I consider all patches on the alsa bug as being part of the
> plugin... I've not looked at our alsa repository for a while but as I
> say I thought they were all committed now.
> 
> It may be worth posting a little prompt to the alsa mailing list.
> Takashi recently committed some of Sjoerd's pulse related stuff to HG,
> so a gentle prod would probably help (perhaps highlighting exactly which
> patches are required to save him wading through that alsa bug!)

I just looked at the current alsa-plugins code. Takashi fixed the 
symptoms, but not the cause of the bug(s). He removed the assertions. 
Errors now are propagated to the application instead of crashing the 
whole application. But the bug that is causing it still remains in the 
code. See comment number 0018163 in the alsa bugtracker. I fixed that in 
the patch I attached to the bug report. Anyhow, that patch fixes 
speaker-test. Wine however needs two additional changes.

First, alsa-pulse doesn't honor the 'start threshold', that is how much 
the application has to write until the pcm is automatically started. The 
alsa pulse plugin harcodes that to 'buffer_size - period_size' but Wine 
sets it to '1'. When Wine writes the first byte, it expects the pcm to 
start. There is a test in Wine where it writes very few data and then 
waits for it to be played. But PA never starts the pcm and Wine ends up 
in an endless loop. The 'start threshold' is part of the software params 
of an alsa pcm.

The second fix needed is for pulse_dealy(). As described in the 
pulseaudio.org ticket, there seems to be a rounding issue. The current 
code uses:
   lat = pa_stream_get_latency()
   delay = snd_pcm_bytes_to_frames(pa_usec_to_bytes(lat))
but I had to change it to:
   delay = snd_pcm_bytes_to_frames(ti->write_index-ti->read_index) - 3000

The '-3000' is needed. If I set it to less, then some of the Wine tests 
fail. Wine uses snd_pcm_delay() to find out how much has already been 
played. Without my change it can happen that snd_pcm_delay() never 
reaches the number of frames that have been written, even after a long time.

tom