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

Andrea wrote:
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.
Sorry, tapping the keyboard to fast. I mean a HTMl view of the soure code, where the different functions, definitions etc are clickable links (as created by e. g., Doxygen)
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: silence_size : 0
  boundary     : 1849688064
Trying to sort this out: I presume the buffer size is 1764 bytes, and there is two channels (i. e., stereo sound). This might mean that the buffer is just one period (441 frames/period * 2 samples/frame * 2 bytes/sample = 1764 bytes). This gives the buffer time 441/44100 => 10000 ns = 10 ms.

That would be a really small buffer, Given an overall requirement of a latency in the 100-150ms area, it's not important. It should be possible to have 2 or three periods without any trouble. If there's latency, it's somewhere else... in the network, or possibly in other sw buffers (RTP?).
If I'm right. This needs a review! I'm far from certain.
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

aplay is an entirely different issue. They don't have to think about latency, just quality. So they make the buffers really large. A VOIP application must make a tradeoff between latency and quality. (And that's why it makes sense to adjust buffer size to network quality).
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
Nor do I. I was just plain wrong in this, it seems. I have some experience with alsa, but have only used pulseaudio as user... stay tuned, I have som reading to do...
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
If you kill the daemon (pulseaudio --kill) and restart ir from a terminal (pulseaudio -D) you might get something like this if there's a problem:I:

 caps.c: Limited capabilities successfully to CAP_SYS_NICE.
I: caps.c: Dropping root privileges.
I: caps.c: Limited capabilities successfully to CAP_SYS_NICE.
N: main.c: Called SUID root and real-time and/or high-priority scheduling was requested in the configuration. However, we lack the necessary privileges:
N: main.c: We are not in group 'pulse-rt', PolicyKit refuse to grant us the requested privileges and we have no increase RLIMIT_NICE/RLIMIT_RTPRIO resource limits.
N: main.c: For enabling real-time/high-priority scheduling please acquire the appropriate PolicyKit privileges, or become a member of 'pulse-rt', or increase the RLIMIT_NICE/RLIMIT_RTPRIO resource limits for this user.
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.
Hm... same for me, for sure. But someone need to have an overall understanding of the buffering, otherwise it's really hard to get things right. Anyone, out there?
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.
OK, that's a "no". Problem is that it's the same for me... Questions, questions. Sorry for bringing all this mess up, maybe it's not exactly on the spot for this issue. But I do think life would be easier if we had some answers. I'll make a (reasonable) try with the pulseaudio docs. The problem is that here are to many loose ends, we need to limit this (my fault).
Skype runs fine with pulseaudio drivers, so it's definitely possible...

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

I'll make a try. Stay tuned... And keep up this important work, it's great someone takes a look at this!

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