# Choppy Playback on Scientific Linux **URL:** \ **Category:** Linux\ **Created:** [September 18, 2014, 8:01pm UTC](https://forum.juce.com/t/choppy-playback-on-scientific-linux/13585 "2014-09-18T20:01:09Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![sfeinstein](https://avatars.discourse-cdn.com/v4/letter/s/9fc29f/32.png) [@sfeinstein](https://forum.juce.com/u/sfeinstein)\ **Post date:** [September 18, 2014, 8:01pm UTC](https://forum.juce.com/t/choppy-playback-on-scientific-linux/13585/1 "2014-09-18T20:01:09Z")
I'm building an application on Scientific Linux 6.3 (x86\_64) and playback on three separate boxes has been sounding like it has buffering issues.  Depending on the audio buffer size, it sounds like gaps inserted into the audio do varying degrees, so it ranges from sounding buzzy to ~200ms gaps.  So to take my code out of the picture, I am running the Juce demo and getting the same results.  I've tried this on Windows and I only hear a problem when I make the audio buffer size small enough (e.g. 352 samples @ 44.1KHz).  But on the Linux systems (which are based on Red Hat code) I get noisy playback for much larger buffer sizes. The device type is ALSA.  If I go with the "default" device, things are better but choppy.  If I pick a different device, things are worse.   Very variable results too...sometimes I fire up the demo and it sounds clean at 44.1K and 512 sample buffers.  Other times it's pops and clicks.  Other times worse. Any hints would be appreciated. ---
**Author:** ![jpo](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/jpo/32/503_2.png) [@jpo](https://forum.juce.com/u/jpo)\ **Post date:** [September 18, 2014, 9:48pm UTC](https://forum.juce.com/t/choppy-playback-on-scientific-linux/13585/2 "2014-09-18T21:48:07Z")
"default" is probably using pulseaudio, right ? If yes, then try to increase the buffer size to 1024 or 2048. Or just kill pulseaudio and try a "direct hardware" device ---
**Author:** ![sfeinstein](https://avatars.discourse-cdn.com/v4/letter/s/9fc29f/32.png) [@sfeinstein](https://forum.juce.com/u/sfeinstein)\ **Post date:** [September 18, 2014, 10:43pm UTC](https://forum.juce.com/t/choppy-playback-on-scientific-linux/13585/3 "2014-09-18T22:43:33Z")
I'm assuming that default = pulseaudio since that is first on the list after default.  But honestly I haven't seen how to tell which device is default - it's always called "Default" everywhere I look (in the code).   The hardware is Creative X-Fi and when I choose that I can hurt my ears on the test tone. Another system has Intel HDA but has the same symptoms.  As far as buffer size with default, I can go all the way up to the max value and still hear a pop or two.  And it's not consistent at all - once in a while I fire up the demo and it plays almost perfectly over and over.  If I change the audio settings though, then it gets messed up the way I'm describing. By the way, aplay works fine. ---
**Author:** ![sfeinstein](https://avatars.discourse-cdn.com/v4/letter/s/9fc29f/32.png) [@sfeinstein](https://forum.juce.com/u/sfeinstein)\ **Post date:** [September 19, 2014, 4:51pm UTC](https://forum.juce.com/t/choppy-playback-on-scientific-linux/13585/4 "2014-09-19T16:51:31Z")
I turned ALSA logging on and sure enough it spits out lots of underrun messages:   ALSA lib pcm.c:7246:(snd\_pcm\_recover) underrun occured ALSA lib pcm.c:7246:(snd\_pcm\_recover) underrun occured ALSA lib pcm.c:7246:(snd\_pcm\_recover) underrun occured ALSA lib pcm.c:7246:(snd\_pcm\_recover) underrun occured ... ALSA: Did not write all samples: numDone: -32, numSamples: 6144     ---
**Author:** ![sfeinstein](https://avatars.discourse-cdn.com/v4/letter/s/9fc29f/32.png) [@sfeinstein](https://forum.juce.com/u/sfeinstein)\ **Post date:** [September 19, 2014, 8:48pm UTC](https://forum.juce.com/t/choppy-playback-on-scientific-linux/13585/5 "2014-09-19T20:48:00Z")
I made the PulseAudio config changes described here... http://tux-is-gaming.blogspot.com/2014/02/fixing-alsa-lib-pcmc7843sndpcmrecover.html ...to tell PA to keep its paws off my ALSA audio stream.   [revisiting months later...] So the above worked, however it also kills any other applications on the system that rely on PulseAudio.  So it's not a solution since there are such applications running in our environment.  The question remains how to get Juce to play correctly on a system with PulseAudio running. As a test, I wrote a command line app a la "aplay" (called it jplay) which is a GUI-less version of the AudioPlayback demo in the Juce demo.  In other words, it uses AudioFormatReaderSource, TransportSource et al to do the playback.  The audio plays flawlessly.  Another test I did was to turn off any painting during playback.  That didn't help.  I also turned off AsyncUpdates from getNextAudioBlock() - also didn't help. Again, the JuceDemo playback has the same scratchy sounds that I get in my app, so I don't think it's specific to my code. Also, the AudioSettings panel also has scratchy playback of the test tone. So, short of writing a PulseAudio driver for JUCE, any ideas of things I should try? ---
**Author:** ![rory](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/rory/32/534_2.png) [@rory](https://forum.juce.com/u/rory)\ **Post date:** [January 16, 2015, 1:54pm UTC](https://forum.juce.com/t/choppy-playback-on-scientific-linux/13585/6 "2015-01-16T13:54:14Z")
> The question remains how to get Juce to play correctly on a system with PulseAudio running. Do you really have to. I played this game for a while, but now I run Jack with all my audio applications and advise users of my software to do the same. I know it's an extra step for the user, but at least you don't have to comprimise your audio.