Bug 39412

Summary: Choppy Sound with Pulsesink on ARM
Product: PulseAudio Reporter: Vallabha <vallabha.pa>
Component: daemonAssignee: pulseaudio-bugs
Status: RESOLVED INVALID QA Contact: pulseaudio-bugs
Severity: normal    
Priority: medium CC: lennart, mkbosmans
Version: unspecified   
Hardware: ARM   
OS: Linux (All)   
i915 platform: i915 features:
Attachments: PulseAudio Traces
Traces after the high resolution timers in kernel were enabled.

Description Vallabha 2011-07-20 23:09:16 UTC
Created attachment 49359 [details]
PulseAudio Traces

I am running PulseAudio on an embedded platform.
When I use paplay utility to play a wav file the audio is clear.
But when I switch to using gstreamer playback via the pulsesink the audio is choppy. I am using default daemon and client conf files.
Attached is the PulseAudio server traces.
More details:
Server: pulseaudio --system --high-priority=1 -vvvvvv
Playback: gst-launch audiotestsrc ! audioconvert ! pulsesink
Comment 1 Vallabha 2011-07-25 04:55:27 UTC
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?
Comment 2 Arun Raghavan 2011-07-25 05:20:30 UTC
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.
Comment 3 Vallabha 2011-07-25 05:24:34 UTC
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
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?
Comment 4 Arun Raghavan 2011-07-25 07:07:20 UTC
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.
Comment 5 Vallabha 2011-07-25 09:16:22 UTC
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.

Comment 6 Vallabha 2011-07-26 22:15:42 UTC
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.
Comment 7 Vallabha 2011-07-26 22:46:16 UTC
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
Comment 8 Maarten Bosmans 2011-10-17 22:38:22 UTC
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?
Comment 9 Arun Raghavan 2011-10-28 04:43:18 UTC
Please update with the information requested and reopen this bug.
Comment 10 Arun Raghavan 2012-03-14 23:41:59 UTC
Please feel to reopen after submitting the requested information.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.