Bug 39412

I did try play around with the latency-time and buffer-time properties of the pulsesink element. It results in audio continuity but I can make out the audio jumps with a media file. 

I also noticed the following message when starting the server:
N: alsa-util.c: Disabling timer-based scheduling because high-resolution timers are not available from the kernel.

Does this mean that the glitch free PulseAudio is not enabled? In such a case should the latency-time of pulsesink be set to ALSA fragment size?

What platform are you running this on? You're right about the log message -- without high-res timers, you can't run in "glitch-free" mode.

Hello Arun,

I am working on an embedded platform.

cat /proc/timer_list
 
gives me following information. Let me know if it suffices PA's requirement. I see that the resolution available is 1/100th of a second.
 
Timer List Version: v0.6
HRTIMER_MAX_CLOCK_BASES: 2
now at 22634717484152 nsecs
cpu: 0
 clock 0:
  .base:       c0460160
  .index:      0
  .resolution: 10000000 nsecs
  .get_time:   ktime_get_real
active timers:
 clock 1:
  .base:       c0460188
  .index:      1
  .resolution: 10000000 nsecs
  .get_time:   ktime_get
active timers:
 #0: <c0484c58>, sched_rt_period_timer, S:01
 # expires at 22635000000000-22635000000000 nsecs [in 282515848 to 282515848 nsecs]
  .nohz_mode      : 1
  .idle_tick      : 22634720000000 nsecs
  .tick_stopped   : 0
  .idle_jiffies   : 2233471
  .idle_calls     : 3361941
  .idle_sleeps    : 3187525
  .idle_entrytime : 22634713881502 nsecs
  .idle_waketime  : 22634713881502 nsecs
  .idle_exittime  : 22634713918152 nsecs
  .idle_sleeptime : 21115835861013 nsecs
  .iowait_sleeptime: 49387606847 nsecs
  .last_jiffies   : 2233471
  .next_jiffies   : 2233500
  .idle_expires   : 22635000000000 nsecs
jiffies: 2233471

Tick Device: mode:     1
Per CPU device: 0
Clock Event Device: gp timer
 max_delta_ns:   214748367050
 min_delta_ns:   1000
 mult:           85899345
 shift:          32
 mode:           3
 next_event:     22634720000000 nsecs
 set_next_event: omap2_gp_timer_set_next_event
 set_mode:       omap2_gp_timer_set_mode
 event_handler:  tick_nohz_handler
 retries:        0

"without high-res timers, you can't run in "glitch-free" mode"

Does this mean, I am bound to encounter audio glitches as one of the blog by Lennart suggests?

Might help to know what kind of CPU/platform it is. As I understand it, on reasonably recent ARM CPUs, timers are sufficiently high resolution to server our needs. So I'm wondering if it's just that your kernel is not compiled with the appropriate flags, or that your CPU itself cannot support µs-resolution timers.

Hello Arun,

Its ARM v7 platform.

As per my previous post, it seems like the kernel is not compiled with high resolution timers.

I will check with the recompiled kernel and update here.

-Rgds
Vallabha

Hello Arun,

The high resolution (1 nsec) timers are now enabled and I now no longer get the PulseAudio message about disabling the timer based scheduling. 

But I still encounter the audio glitches when using pulsesink.

Created attachment 49596 [details]
Traces after the high resolution timers in kernel were enabled.

Traces after the high resolution timers were enabled. Still able to hear the audio glitches.

gst-launch filesrc location=some_mp3.mp3 ! mad ! audioconvert ! pulsesink latency-time=25000 buffer-time=2000000

How about playing a wav file with gstreamer or a compressed file (.ogg) with paplay?

I'm just wondering whether it's something with latency that gstreamer requests, or simply a CPU thing because of the decoding of the compressed file. How is CPU usage during playback?

Please update with the information requested and reopen this bug.

Please feel to reopen after submitting the requested information.