So I already finished upgrade to opensuse 13.2. After do zypper dup, there is no problem except when I play some video online or offline, the sound is choppy. Any idea? I already installed multimedia codecs and disable the pulse audio.
I’m not a sound guru, but to start with perhaps worth trying the following
https://en.opensuse.org/SDB:Audio_troubleshooting#A_possible_fix_to_choppy_.2F_skipping_sound
try replacing the line load-module module-udev-detect in /etc/pulse/default.pa by (or adding if that line not present) load-module module-udev-detect tsched=0 In other cases, choppy sound in pulsaudio can result from wrong settings for the sample rate in /etc/pulse/daemon.conf . Try changing the line default-sample-rate = 44100 in /etc/pulse/daemon.conf by default-sample-rate = 48000 and restart the PulseAudio server.
I think that quoted approach is intended to help those who state they get choppy sound with pulse audio enabled. In the OP’s case, they claim they have choppy sound with pulse audio disabled. Hence that leads me to believe the problem is elsewhere.
I have read (recently) in the mailing list, that a mal behaved app could monopolize on the output of the alsa api and cause choppy sound for other apps, including pulse audio. But there is no way of telling if this the case for the OP, and my own suspicion is that it is not (the case).
.
You’re correct. I missed the PA disabled bit. Sorry about that. 
Some process may be hogging resources. Run top and see if something is using all the cpu.
Further to this, in the ‘old days’ prior to pulse with much earlier GNU/Linux versions, one could see which application was using the audio device by typing:
lsof /dev/dsp* /dev/audio* /dev/mixer* /dev/snd/*
Today it has all changed, and I do not know what command would be sufficiently all inclusive. Possibly just:
lsof /dev/snd/*
would suffice … but I really don’t know anymore.
On 2014-12-15 04:06, oldcpu wrote:
> Code:
> --------------------
>
> lsof /dev/dsp* /dev/audio* /dev/mixer* /dev/snd/*
>
> --------------------
I do get output with that, some owned by pulseaudio and some by others.
Things are complex indeed…
It should produce some output for the OP.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Here I get
gogalthorp@linux6:~> lsof /dev/dsp* /dev/audio* /dev/mixer* /dev/snd/*
lsof: status error on /dev/dsp*: No such file or directory
lsof: status error on /dev/audio*: No such file or directory
lsof: status error on /dev/mixer*: No such file or directory
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
pulseaudi 3682 gogalthorp 16u CHR 116,10 0t0 9263 /dev/snd/controlC1
pulseaudi 3682 gogalthorp 23u CHR 116,10 0t0 9263 /dev/snd/controlC1
pulseaudi 3682 gogalthorp 24u CHR 116,6 0t0 9220 /dev/snd/controlC0
pulseaudi 3682 gogalthorp 31u CHR 116,6 0t0 9220 /dev/snd/controlC0
pulseaudi 3682 gogalthorp 36u CHR 116,6 0t0 9220 /dev/snd/controlC0
So only /dev/snd/ is defined
If any other app is using the sound device it can block pulse or other sound servers
But choppy sound is usually CPU utilization. If a new install maybe an indexer is running.
On 2014-12-15 19:26, gogalthorp wrote:
>
> Here I get
>
>
> Code:
> --------------------
>
> gogalthorp@linux6:~> lsof /dev/dsp* /dev/audio* /dev/mixer* /dev/snd/*
> lsof: status error on /dev/dsp*: No such file or directory
> lsof: status error on /dev/audio*: No such file or directory
> lsof: status error on /dev/mixer*: No such file or directory
> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
> pulseaudi 3682 gogalthorp 16u CHR 116,10 0t0 9263 /dev/snd/controlC1
> pulseaudi 3682 gogalthorp 23u CHR 116,10 0t0 9263 /dev/snd/controlC1
> pulseaudi 3682 gogalthorp 24u CHR 116,6 0t0 9220 /dev/snd/controlC0
> pulseaudi 3682 gogalthorp 31u CHR 116,6 0t0 9220 /dev/snd/controlC0
> pulseaudi 3682 gogalthorp 36u CHR 116,6 0t0 9220 /dev/snd/controlC0
>
> --------------------
>
> So only /dev/snd/ is defined
Mine is weird.
Telcontar:~ # lsof /dev/dsp* /dev/audio* /dev/mixer* /dev/snd/*
....
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
pulseaudi 4537 cer 16u CHR 116,7 0t0 11300 /dev/snd/controlC0
pulseaudi 4537 cer 23u CHR 116,7 0t0 11300 /dev/snd/controlC0
pulseaudi 4537 cer 28u CHR 116,7 0t0 11300 /dev/snd/controlC0
panel-16- 5516 cer 8u CHR 116,7 0t0 11300 /dev/snd/controlC0
panel-16- 5516 cer 9u CHR 14,0 0t0 11301 /dev/mixer
xfce4-vol 5697 cer 8u CHR 116,7 0t0 11300 /dev/snd/controlC0
xfce4-vol 5697 cer 9u CHR 14,0 0t0 11301 /dev/mixer
Telcontar:~ #
You see, not all are pulseaudio processes, yet things work just fine. I
think. Although I don’t understand it :-}
My guess is that the mixers above are wrong.
> If any other app is using the sound device it can block pulse or other
> sound servers
Yes, so I understand.
> But choppy sound is usually CPU utilization. If a new install maybe an
> indexer is running.
That should not ever happen.
I experimented with sound under MsDos in my own programs. I could get,
in a plain 8086 (8 Mhz), smooth sound at the same time as my normal code
run, be it a text display or a game or intense matrix calculations. I
tried to break it, but it worked. I just used Turbo Pascal… not even
assembler.
I simply used interrupts.
So if I could do it in ~1987, programmers in 2014 with the wonderful
hardware and software they have available can do much better than I did.
Choppy sound because the CPU is busy is plain unacceptable.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
I finally fixed it. I just turn off the auto mute and the sound is working normally without problem.
Ah, so none of the above. This option is obviously specific to your hardware. (I don’t have it.) Might be useful to others who come searching though.
On 2014-12-16 08:46, mki wrote:
>
> I finally fixed it. I just turn off the auto mute and the sound is
> working normally without problem.
Auto mute? What does that do? I’ve not seen it. :-?
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
I have seen both sound and graphics stutter if a process goes zombi or even an aggressive Indexer (I hate them )
In 8086 day it was simple connect sound source to hardware. Today we have layers and layers of audio control and filtering. Also in 8086 days one app could use the sound at a time.
But then it was pretty much run one app at a time anyway LOL
On 2014-12-16 20:06, gogalthorp wrote:
>
> I have seen both sound and graphics stutter if a process goes zombi or
> even an aggressive Indexer (I hate them )
>
> In 8086 day it was simple connect sound source to hardware. Today we
> have layers and layers of audio control and filtering. Also in 8086 days
> one app could use the sound at a time.
Simpler in the sense that we had full control. Harder in the sense that
we had to do it all, with scarce resources in many senses.
> But then it was pretty much run one app at a time anyway LOL
Yes. To run a task on background we had to tap into an interrupt. I
tapped into the clock interrupt, which was called 19.2 times per second.
It was curious that my application might crash or get into a loop, but
sound kept playing.
To crash sound either my sound code itself crashed, or the “normal” code
crashed at a point where interrupts were banned, which are very few. Of
course, sound stopped if the buffer emptied and nothing was running that
could fill it up again; this happened because an optimization was to not
load the entire sound file in ram from the start (it was not a loop, but
an opera introductio 
— on the internal speaker)
The situation is similar today, somewhat. There will be code, indirectly
controlled via clock interrupts (ie, now system timer callbacks or
whatever they use now), small and tight, and other code with normal
priority that basically feed the buffers.
More or less
The kernel needs have some Real Time features to ensure that the sound
pipe has data and doesn’t stutter.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
I just turn off the auto mute via alsamixer
But that’s for TW and factory version. I’ll stick with kde plasma 4.14.