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



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.

OK, this is haunting me. To get some peace of mind I need to sort this out, at least for myself.
From the alsa docs:

snd_pcm_status_get_avail_max: Get maximum number of frames available from a PCM status container after last snd_pcm_status <http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#g3517971b4faf263cf91d146b5a07169d> call.
snd_pcm_status_get_avail: Number of frames ready to be read/written

snd_pcm_status_get_delay: Delay is distance between current application frame position and sound frame position. It's positive and less than buffer size in normal situation, negative on playback underrun and greater than buffer size on capture overrun.
-----------------------------------

So: "avail" is the number of frames the app (opal) can write to alsa. I doubt the other figures are relevant, and they might certainly be hard to define in the emulated alsa interface provided by pulse.
Something is strange in the "direct" logs. Looking at the "avail" 
figures, its something like (after an initial phase): 459, 21,  446, 9, 
443, 6, 446, 9, 483, 46, 444, 6, ...the pattern is obvious. I interpret 
it as something is out of phase between the app (opal?) and the alsa 
layer.  Ideal, these figures should be something around 446, 444, 489, 
444, ... ( application writes as soon as there is space to write one 
period). Possibly nothing is written when avail is small, but it's still 
not as it should be.
BTW, the "direct" logs shows that avail_max  don't excceds 1000 frames - 
it's roughly  800-900. If this is typical, it should be possible to 
decrease the buffer to 3 periods (1323 frames)  without any significant 
underrun rate.  But this is not important now.
As for the alsa logs, the xruns are the endpoint  when the avail drops 
in four steps:  1322, 882, 441, 0/xrun. This is almost exactly 3 
periods, 2 periods, 1 period, xrun. It looks like the xrun occurs when 
avail drops to 0 - which is more than strange. Something is broken also 
here, I presume this is the same problem as in the "direct" case.
It might be an idea to put some timestamps around  the debug printouts 
just to make sure the very presence of them don't  disturb the timing. I 
don't think so, but I once, when working with something similar, 
remember storing figures in a buffer only written now and then. It was 
most likely overkill. But just to be sure...
I really wish I had more time. But as I see it, these printouts implies 
something strange in the current alsa handling, and that this propably 
ought to be sorted out before trying pulse. 

As usual, that's if I'm right...Isn't there any other alsa people out there?



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