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. > > 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: 0 silence_size : 0 boundary : 1849688064 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 > 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. > > 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. > > 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. > 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. > Skype runs fine with pulseaudio drivers, so it's definitely possible... Maybe you could dump the setup used by skype, via some /proc/file... _______________________________________________ ekiga-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/ekiga-list
