[pulseaudio-discuss] cracks and pops with intelHDA

[Lennart Poettering]

On Mon, 07.01.08 13:48, 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.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.

Don't do this. As mentioned, renicing still has some benefit for PA,
event if you enable RT.

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

real-time scheduling is essential for low latency audio.

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

May I ask why you use 192khz? Don't tell me you hear the difference!
(Gold Cables are too!)

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

The PA API offers enough hooks to allow client applications to change
the volume of their streams in PA easily. Unfortunately no application
uses this right now. Stuff like Rhythmbox unfortunately insists in
doing volume control in SW.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4