Hi, I've tried to compare the behaviour of ALSA when Ekiga uses the direct access vs going through pulse-alsa module. I've added some alsa print status in ptlib and the 2 files are the output when playing the ring-tone. I've used the 2 alsa calls to populate the log 1) snd_pcm_dump at the beginning 2) snd_pcm_status_dump after each write The first part is the same, but the status after each write is different DIRECT About to write 1764 len bytes state : RUNNING trigger_time: 9762.542972003 <<<<<<<<<<<<<<<<<<<<<<<< tstamp : 9762.543004130 <<<<<<<<<<<<<<<<<<<<<<<< delay : 430 <<<<<<<<<<<<<<<<<<<<<<< avail : 1334 avail_max : 1334 PULSE About to write 1764 len bytes state : RUNNING trigger_time: 1235218239.552437000 <<<<<<<<<<<<<<< tstamp : 0.000000 <<<<<<<<<<<<<<< delay : 0 <<<<<<<<<<<<<<< avail : 441 avail_max : 1764 And then every now and then when running via pulse we generate an underrun About to write 1764 len bytes state : RUNNING trigger_time: 1235218239.552437000 tstamp : 0.000000 delay : 0 avail : 0 avail_max : 1764 ####################################################################### EPIPE state : XRUN trigger_time: 1235218239.552437000 tstamp : 0.000000 delay : 0 avail : 0 avail_max : 1764 Does anybody know a bit what all those values mean? It seems that the underrun comes earlier that without pulse-alsa... I've tried to increase the size of the buffers in PSoundChannelALSA::SetBuffers() and the playback is much better, but that gives a bigger latency and delay when calling the echo test.
Attachment:
status.direct.txt.gz
Description: GNU Zip compressed data
Attachment:
status.pulse.txt.gz
Description: GNU Zip compressed data