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

[Andrea <mariofutire googlemail com>]

Alec Leamas wrote:
> 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.

Sorry, I don't understand what you mean.

> 
> 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.

It is at the beginning of the 2 files (the same):

Its setup is:
  stream       : PLAYBACK
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 2
  rate         : 44100
  exact rate   : 44100 (44100/1)
  msbits       : 16
  buffer_size  : 1764
  period_size  : 441
  period_time  : 10000
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 441
  period_event : 0
  start_threshold  : 1
  stop_threshold   : 1764
  silence_threshold: 0
  silence_size : 0
  boundary     : 1849688064

As a comparison this is what alsa's aplay uses when playing the same file

Its setup is:
  stream       : PLAYBACK
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 2
  rate         : 44100
  exact rate   : 44100 (44100/1)
  msbits       : 16
  buffer_size  : 22050
  period_size  : 5512
  period_time  : 125000
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 5512
  period_event : 0
  start_threshold  : 22050
  stop_threshold   : 22050
  silence_threshold: 0
  silence_size : 0
  boundary     : 1445068800

> 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?

I am not sure I follow, since there are 2 patterns here

alsa-pulse-alsa: delay = 0, avail_max=1764 and avail in between
alsa direct:     delay + avail = 1764, avail_max varies

1764 seems to be the size of the hw buffer.

> 
> 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?

I use the default, no idea what to check here.

> 
> 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.

Sorry, but this goes beyond my current understanding.

> 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?
> 

Not sure.

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

Maybe you could dump the setup used by skype, via some /proc/file...