On 20 Nov 2007, Lennart Poettering told this:
> On Sun, 04.11.07 12:16, Nix (nix at esperi.org.uk) wrote:
>
>> hades# /usr/bin/pulseaudio --daemonize=no
>> 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: ""): initialization failed.
>> E: main.c: Module load failed.
>> E: main.c: failed to initialize daemon.
>
> Please run pulseaudio -vv.
Oo, there's a -vv? I didn't notice...
>> ioctl(16, 0xc0684113, 0xbf938128) = 0
>> ioctl(16, 0x80144132, 0xbf93805c) = -1 ENOTTY (Inappropriate ioctl for device)
>>
>> Of course none of these ioctls are documented anywhere: in fact I can't
>> even find them in the kernel source (although they must be there
>> somewhere, one assumes).
>
> Those ioctls are ALSA-specific.
I guessed that: item #3 on my todo list was to dig through alsa-lib and
figure out what they did, but now you're back I probably won't get
around to it before you spot whatever's wrong :)
>> I'm just wondering if this is an error in the way PulseAudio is *using*
>> ALSA, or if I should jump up and down on the ALSA list instead?
>
> Could you please change default.pa, disable both detection modules and
> instead use "load-module module-alsa-sink device=plughw:0"?
plughw? ... OK, helpfully documented in the alsa-lib source code...
The pulseaudio startup still fails but has some interesting extra errors:
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.)
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
The ALSA parts of my kernel config are:
CONFIG_SOUND=y
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
CONFIG_SND_HWDEP=y
CONFIG_SND_RAWMIDI=y
CONFIG_SND_SEQUENCER=y
CONFIG_SND_SEQ_DUMMY=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
CONFIG_SND_PCM_OSS_PLUGINS=y
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=y
CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y
CONFIG_SND_SUPPORT_OLD_API=y
CONFIG_SND_VERBOSE_PROCFS=y
CONFIG_SND_MPU401_UART=m
CONFIG_SND_AC97_CODEC=y
CONFIG_SND_MPU401=m
CONFIG_SND_EMU10K1=y
CONFIG_SND_INTEL8X0=y
CONFIG_AC97_BUS=y
CONFIG_HID_SUPPORT=y
(none of the modular bits are loaded right now.)
--
`Some people don't think performance issues are "real bugs", and I think
such people shouldn't be allowed to program.' --- Linus Torvalds
