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

[Alec Leamas <leamas alec gmail com>]

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