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

[Alec Leamas <leamas alec gmail com>]

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!