Comment 126 for bug 345627

On Tue, Jun 30, 2009 at 10:52 PM, Conn<email address hidden> wrote:
> First, a question: why did kernel 2.6.30-10-generic trigger bug #374002,
> when it was supposed to be fixed since kernel 2.6.29 according to
> Fedora's bug report related to my particular codec [2]? As I said
> earlier, this bug did not occur when I tested Fedora 11 on my laptop.

2.6.30 does not contain all the core/pcm mid-layer fixes that 2.6.31-git does.

Note also that Fedora 11, Ubuntu Jaunty, and Ubuntu Karmic have
different audio stacks.

> Second, a proposal: let's enable glitch-free playback and revert the
> modifications to the default-resampler, default-fragments and default-
> fragment-size-msec parameters.

The latter two modifications don't make any difference when
glitch-free is enabled. I dogfood before putting changes into the
Ubuntu repository: to that end, for a bit I've tested 2.6.31-rc1-fix1
and glitch-free enabled with much improved results on a lot of
hardware (AC'97-, HDA-, USB-based).

So, yes, it makes sense to stop applying those two quilt patches to
Karmic's pulse source.

> (even though my particular codec appears fixed)

Distinction: we work around your broken controller (your codec is
quirky but not relevant here).

> a) interrupt-based playback in PulseAudio really is "glitchy", and audio quality is suffering for everyone on Karmic as a result;

Ubuntu also does not use HZ=1000 combined with NOHZ or PREEMPT, unlike Fedora.

> b) the resampler/fragment modifications we use in Ubuntu are poor workarounds [3] for the erratic buffering behaviour in certain applications (Skype) and CPU usage caused by interrupt-based playback in PulseAudio;

Agreed (in the past there were concerns about limiting CPU usage for
low-powered devices).

> c) There is no guarantee that we can resolve the current stuttering/buffering issues with interrupt-based playback, as it seems pretty obvious that the majority of development is focused on glitch-free playback in PulseAudio;

Agreed, it's really an intractable problem, because far too much
hardware is plain broken.

> d) We are depriving ourselves of the opportunity to co-operate with the PulseAudio, Fedora, ALSA and upstream kernel developers in squashing the remaining bugs in PulseAudio and the ALSA kernel drivers that glitch-free playback exposes.

Timing is perhaps the biggest factor. These changes are queued, but
they weren't going to be put into Karmic without a 2.6.31-rc1-based
kernel landing first.

> I am aware that some sound cards may never work correctly with glitch-
> free (due to poor hardware documentation), but perhaps we can consider a
> method to blacklist cards later on - let's cross that bridge when we
> come to it.

Presently there is no callback into the driver for such information,
so we are incapable of doing so. Also, there are far too many hardware
combinations. It's much easier to simply disable glitch-free for those
cards.