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