[pulseaudio-discuss] cracks and pops with intelHDA

[Ritesh Kumar]

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.8 which
> > 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 have a similar problem in that a pulse stream plays for a few moments,
> starts to hiccup and then stops altogether. It doesn't matter which
> program I use. Using alsa directly there is no problem. On my other
> computer it works like expected, though. I have no need to use pulse
> anymore (it doesn't solve my problem) so my problem is gone ;-)
>

:)
I needed low latency mixing (primarily)... and the convenience of switching
between audio sinks dynamically (secondarily). I like the idea of per
application volume mixing but I would rather keep the UI component tied to
the application itself than keep it separate... I am guessing pulseaudio
does provide a mixer/sink manipulation API... a little gtk+ embeddable
component to control these easily would provide a consistent audio control
interface across many applications.

What was problem you wanted to solve... (network audio?). May be I can help.

_r
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20080107/93f19d92/attachment.htm>