[pulseaudio-discuss] pulseaudio with kernel 2.6.23 (and earlier?) insists on using OSS, not ALSA

[Nix]

On 25 Nov 2007, Lennart Poettering verbalised:

> On Thu, 22.11.07 01:29, Nix (nix at esperi.org.uk) wrote:
>
>> I: core-util.c: Successfully gained nice level -11.
>> I: main.c: Found user 'pulse' (UID 31) and group 'pulse' (GID 62).
>> I: main.c: Successfully dropped root privileges.
>> I: main.c: Page size is 4096 bytes
>> I: main.c: Dude, your kernel stinks! The chef's recommendation today is Linux with high-resolution timers enabled!
>> E: module-alsa-sink.c: Failed to set hardware parameters: Inappropriate ioctl for device
>> E: module.c: Failed to load  module "module-alsa-sink" (argument: "device="plughw:0""): initialization failed.
>> E: main.c: Module load failed.
>> E: main.c: failed to initialize daemon.
>> I: main.c: Daemon terminated.
>> 
>> (of course it fails in just the same way if run non-systemwide: I'm only
>> using a systemwide instance because I like to get sound even when X
>> isn't running.)
>
> Hmm, could you please report this to the ALSA people? This looks like
> an ALSA problem.

I'll do that as soon as I can get to alsa-project.org at all. (I believe
I said something about broadband in the UK sucking enormously. The
whole street is also having major power failures, half of each day with
no power :/ )

> Hmm, is it possible that you are using incompatible versions of
> alsa-lib and the in-kernel ALSA stuff? Maybe some left-over alsa-lib
> in /usr/local?

Nope, I'm certain that the only alsa-lib on this box is 1.0.15.

(But perhaps 1.0.15 is aimed at kernel 2.6.24-to-be. This is sort of
hard to determine: I haven't found any list anywhere of which ALSA
versions are meant to be compatible with which kernels...)

I'll try backing down to 1.0.14 and see how that works.

>> I'd fix the `your kernel stinks', only hrtimers *are* enabled, and the
>> clock_getres() call succeeds! ALSA seems to be tripping things up again:
>> 
>> clock_getres(CLOCK_MONOTONIC, {0, 999848}) = 0
>> ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfc58650) = -1 EINVAL (Invalid argument)
>> write(2, "I: main.c: Dude, your kernel sti"..., 115I: main.c: Dude, your kernel stinks! The chef's recommendation today is Linux with high-resolution timers enabled!
>> ) = 115
>
> clock_getres should return {0, 1} or suchlike if hrtimers are
> available. Please note that hrtimers are only available on x86 (not
> even x86-64) on released kernels right now. Are you running x86-64?

Nope, x86.

Time to debug before I bother you any more. The fun thing about running
a compiled-from-source all- bleeding-edge system is that you never run
out of bugs to hunt down :) indeed this is why I do it, but I don't want
this peculiar personal choice of mine to cause more workload for anyone
else. This bug is my fault until I've proved otherwise...


(I just have some bugs in XEmacs CVS HEAD and perl to kill first...)

-- 
`Some people don't think performance issues are "real bugs", and I think 
such people shouldn't be allowed to program.' --- Linus Torvalds