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