[pulseaudio-discuss] cracks and pops with intelHDA

Ritesh Kumar ritesh at cs.unc.edu
Sat Jan 12 10:49:24 PST 2008

On Jan 7, 2008 1:48 PM, Ritesh Kumar <ritesh at cs.unc.edu> wrote:

> On Jan 7, 2008 11:59 AM, Erik Slagter <erik at slagter.name> wrote:
> > > I was wondering if anybody was experiencing random cracks and pops
> > (loud
> > > ones actually :( ) while using pulseaudio with intelHDA? I have the
> > > following configuration for my inbuilt intelHDA card and will be
> > > thankful if somebody helped me out here. I haven't observed cracks and
> > > pops on my other card (Griffin iMic). I am using pulseaudio 0.9.8which
> > > is able to acquire realtime scheduling priority and a nice level of
> > -11.
> >
> > If you have true realtime scheduling, you don't need "nice" levels. If a
> > process in the realtime queue is ready to run, it will run, even if
> > there are dozens of processes in the "normal" queue ready to run and
> > even if they are all nice'd -19 (the maximum).
> >
> Hmmm... I am sure you are right. Will probably switch off renicing then.
> > Besides that, a properly designed sound system (software and hardware)
> > doesn't need a high priority to work smoothly.
> >
> You mean even at low latencies?... quite a few people had me convinced
> otherwise. I was under the impression that realtime sound processing was
> important for directly interfacing musical instruments with a computer...
> may be not for day to day audio needs I guess. However, I do recall using
> ecasound with my guitar... I never prioritized ecasound (with rtlowlatency
> buffering running directly over alsa hw) though and characterized the cracks
> and pops I heard then to the same.
> > So you have another problem here, actually. How is sound reproduction
> > using purely alsa (without pulse)?
> >
> I had no such  cracks and pops earlier with alsa+dmix running at 192Khz. I
> had even added the speex resampler to alsa+dmix and faced no problems. The
> CPU usage for the audio application used to go up quite a bit (14%) due to
> the resampling but that's expected. However I did notice a good amount of
> latency then with games which I played through alsa-oss. I won't say padsp
> is perfect but it is surely much better latency wise.
> Please note that the applications I am using send sound to pulseaudio
> using either gst-pulse or alsa-pulse... and I saw cracks and pops with both.
I am running pulseaudio without any cracks and pops now. The difference is
that now the intel HDA sink runs at 48kHz instead of 192kHz. However, the
cracks and pops come back after a suspend-to-ram.
I also removed fifo scheduling... (back to the default pulse 0.9.8 setup;
nicing only)... it didn't seem to have an effect.

This brings up two questions:
1) Can suspend-to-ram cause timing problems in pulseaudio? If not then the
kernel's USB audio driver seems to be doing something fishy here.
2) Why did intel mandate 192kHz audio sampling in intel HDA? Are there any
applications for such high sampling rates?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20080112/2abd2df2/attachment.htm>

More information about the pulseaudio-discuss mailing list