Re: [Ekiga-list] A comparison ALSA-PULSE

[Alec Leamas <leamas alec gmail com>]

Just some thoughts. Maybe it can provoke someone who knows better... If 
we had a pointer to cress-referenced code of the *dump routines we would 
be on much safer ground.

It would be interesting to know the basic characteristics: sample rate, 
frame size, samplesize, period size...I remember something like cat 
/proc/asound/card0/pcm0p/sub0/hw_params, cat 
/proc/asound/card0/pcm0c/sub0/sw_params to get this info.

I interpret delay as the time the calling routine has to sit waiting 
until there is space enough in the hardware buffer to write. 

Available reflects the numbers of (bytes? frames? samples?)  available 
in the hw buffer for the sound card?

Available_max: isn't this just the size of the hw buffer, in something( 
bytes? frames? samples?) i. e., the max number  of entities which could 
be buffered?

Isn't  "trigger time"  the time between each interrupt, basically the 
thing you are waiting for in snd_pcm_wait()?

Is pulseaudio running with  high nice value?

Is the RTP jitter buffer a separate buffer, or is it using the alsa 
buffer for this purpose? Separate playback buffers is a major drawback, 
they add latency without being available to avoid underruns. Maybe it's 
possible to increase the alsa buffer and decrease the RTP playback 
buffer? Same latency, but less chance of underrun... There are 
real-world examples of hw buffers ~3600 bytes, with very acceptable 
latency (i. e., twice the buffer size here). But then that's the only 
buffers.... and it depends on samplerate etc.

Alsa underruns behaves very differently depending on the calling 
routines.  I don't know whether pulse handles underruns internally (they 
should!), or if it's a requirement for client code. Is this sorted out?

Skype runs fine with pulseaudio drivers, so it's definitely possible...


Andrea wrote:
> 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.
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> ekiga-list mailing list
> ekiga-list gnome org
> http://mail.gnome.org/mailman/listinfo/ekiga-list