[pulseaudio-discuss] Moving sources and sinks
tom at dbservice.com
Sun May 4 07:27:08 PDT 2008
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).
> 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
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.
More information about the pulseaudio-discuss