[pulseaudio-discuss] PulseAudio 0.9.15 and no sound on Ubuntu

[Luke Yelavich]

On Fri, May 15, 2009 at 03:07:02PM EST, Luke Yelavich wrote:
> I have just tried using speech-dispatcher with pulseaudio, as per the latest changes from CVS, with version 0.9.15 of pulseaudio on Ubuntu Karmic, with a recompiled kernel to enable preempt, and set Hz to 1000. I am using a Realtek ALC885 hda chip with glitch-free enabled, and default speech-dispatcher configuration, except for using pulseaudio for output, with the espeak speech synthesizer.
> 
> Speech-dispatcher through pulseaudio now seems to behave worse than prior to the changes in cvs. Speech seems to react quickly enough when you attempt to speak a line of text using the Orca screen reader for example, however if that line of text is long, and you press a key to move onto the next line, speech doesn't cut off immediately and start on the next line. The first line finishes speaking first, then the second line is spoken. The audio from the speech synthesizer via pulse also breaks up every second or so for maybe a second, then resumes speaking. I'll revert the changes from CVS to be sure I correctly recall how speech-dispatcher + pulseaudio behaved.

Ok, I have a better idea of whats going on here. I'll describe the behavior as I see it with glitch-free enabled, and glitch- free disabled. These tests were conducted with latest CVS code of speech-dispatcher, the Orca screen reader for the GNOME desktop version 2.27.1, with kernel 2.6.30-rc5, with CONFIG_PREEMPT enabled, and CONFIG_HZ_1000 enabled. The sound hardware in use once again is a Realtek ALC885 hda chip.

With glitch-free enabled, the response time from pressing a key, say the down arrow key to move to a line of text is different, depending on whether there is currently text being spoken. If you press a key to read a line of text from a standing start, i.e no text is being spoken, then there is very little time between pressing a key and hearing the first part of the text spoken. Not quite as fast as what is possible with alsa, but still quite fast. If the line of text is long, then due to PulseAudio's glitch-free buffering symantics, the line of text breaks up regularly, then about a half second of silence, then more text spoken, and so on. When I arrow to the next line of text, the remaining buffer for the first line of text speaks, then about a half second gap, then the second line I arrowed to, starts to speak. Pressing the control key to flush speech is not nearly as responsive as arrowing to a line to start speaking text from a standing start.

With glitch-free disabled, the response time between pressing a key to read a line of text from a standing start is a little more than with glitch-free enabled, certainly not as fast as whats possible when using alsa, and certainly not fast enough for day to day use. However, the whole line of text is spoken, without any gaps. Flushing takes about the same time as it does with glitch-free enabled.

I've attached a log of pulseaudio's output during the glitch-free session. I haven't yet made a log of a session without glitch-free, but I can if required. One thing to note is that the sample rate used is 22050, and the audio is mono. I also get the following assertion error occasionally, no matter the session:

Assertion 'q->front' failed at pulsecore/queue.c:83, function pa_queue_push(). Aborting.

Hope this helps.

Luke
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pulse.log.gz
Type: application/octet-stream
Size: 7530 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20090515/1bc96e65/attachment.obj>