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



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]