I haven't yet fully debugged this one, but here's what I've got so far.
I'm using kernel 2.6.23, and alsa-lib 1.0.15 with an emu10k1-based card
(an SBLive CT4620).
As of (I think) kernel 2.6.23 (but maybe earlier versions and I just
didn't notice?), PulseAudio (0.9.6 and 0.9.7 both) refuses to talk to
ALSA: it only works with OSS (excellently, as ever).
The hardware-detect module always gives me OSS (module-hal-detect
sometimes gives me OSS and sometimes refuses to start because it tries
to give me ALSA and this happens, so I've disabled it: I'm prepared to
lay all the blame at bloody HAL's feet for that one and am not even
bothering to *try* to debug it, life is too short for HAL).
If I explicitly load the ALSA sink/source:
load-module module-alsa-sink
load-module module-alsa-source
Then I get:
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.
(An strace is attached.)
The significant part of the strace appears to be:
open("/dev/snd/pcmC0D0p", O_RDWR|O_NONBLOCK|O_LARGEFILE) = 16
ioctl(16, AGPIOC_ACQUIRE or APM_IOC_STANDBY, 0xbf93811c) = 0
fcntl64(16, F_GETFL) = 0x8802 (flags O_RDWR|O_NONBLOCK|O_LARGEFILE)
ioctl(16, AGPIOC_INFO, 0xbf9382c8) = 0
ioctl(16, AGPIOC_RELEASE or APM_IOC_SUSPEND, 0xbf9382c0) = 0
mmap2(NULL, 4096, PROT_READ, MAP_SHARED, 16, 0x80000) = 0xb7ff8000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 16, 0x81000) = 0xb7ff7000
[huge flood of ioctls culminating in...]
ioctl(16, 0xc25c4110, 0xbf9381bc) = 0
ioctl(16, 0xc25c4110, 0xbf9381bc) = 0
ioctl(16, 0xc25c4110, 0xbf9381bc) = 0
ioctl(16, 0xc25c4110, 0xbf938540) = 0
ioctl(16, 0xc25c4111, 0xbf938540) = 0
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).
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?
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pulseaudio.trace
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20071104/fdda575c/attachment.asc>
