[pulseaudio-discuss] pulseaudio 0.9.8 still unhappy with ALSA (for different reasons?)

Sun Nov 25 16:35:06 PST 2007

On 25 Nov 2007, Lennart Poettering uttered the following:

> On Fri, 23.11.07 00:00, Nix (nix at esperi.org.uk) wrote:
>
>> The error from ALSA has changed but is still, well... an error:
>> 
>> nix at hades 90 /home/nix% /usr/bin/pulseaudio -vv --daemonize=no
>> pulseaudio: modules/module-alsa-sink.c:177: mmap_write: Assertion `(areas[0].step >> 3) == u->frame_size' failed.
>> Aborted
>
> Hmm. This doesn*t look good. What kind of device is this? This is
> really a strange error.

emu10k1:

00:05.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 04)
        Subsystem: Creative Labs CT4620 SBLive!
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (500ns min, 5000ns max)
        Interrupt: pin A routed to IRQ 16
        Region 0: I/O ports at d400 [size=32]
        Capabilities: [dc] Power Management version 1
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

Kernel 2.6.23.8, sound config like so:

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_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_AC97_CODEC=y
CONFIG_SND_EMU10K1=y

(hm, it looks like CONFIG_SND_INTEL8X0 got turned on too, but since I
don't have one of those, I doubt it's done any harm...)

>> (The EPERM errors are my fault, I think: a PAM config bug, perhaps,
>> although it's not obvious. The hires timer thing remains undiagnosed so
>> far.)
>
> The hrtimer warning just tells you to get a better kernel with
> hrtimers enabled. That's all. PA works fine without them, but it's
> recommended to have them.

Er...

CONFIG_HIGH_RES_TIMERS=y

And glibc 2.7, which certainly has hrtimer support. What else is needed?

(I'd have debugged this this weekend, only work insisted on my blowing
time on their stuff instead. With luck they might even pay me for it.
Oh look, a flying pig...)

>> So I suspect plughw:0 simply doesn't exist, or something (whatever it
>> is).
>
> This is not an error. PA tries to find a suitable mixer device for
> your PCM. First it tries "plughw:0" and then it falls back to
> "hw:0". ALSA likes to be quite verbose on this. It shouldn't
> be. Complain to ALSA.

OK, I suspected it was an unimportant moan. The frequency of those is
why I compiled alsa-lib with debugging support off in the first place,
and when this is fixed it's getting turned off again. It's quite a
spammy library...

>> When it boots successfully (using a hardwired OSS), I get some rather
>> strange log messages:
>> 
>> Nov 22 22:47:51 hades err: pulseaudio[6242]: socket-server.c: socket(PF_INET6): Address family not supported by protocol
>> Nov 22 22:47:51 hades err: pulseaudio[6242]: socket-server.c: socket(PF_INET6): Address family not supported by protocol
>> Nov 22 22:47:51 hades err: pulseaudio[6242]: socket-server.c: socket(PF_INET6): Address family not supported by protocol
>> Nov 22 22:47:51 hades err: pulseaudio[6242]: socket-server.c:
>> socket(PF_INET6): Address family not supported by protocol
>
> A kernel without IPV6? So we are living in the early nineties now?

I don't compile it in because I don't use it: the local net has three
machines on it (IPv6: overkill) and my ISP doesn't support it, so the
only point of building it in is to waste nonswappable memory in order to
run IPv6 tunnels, which do nothing useful other than consume bandwidth
on my already too-slow network connection with packet headers. :)

Basically no UK ISPs support IPv6 except via tunnels, and the state of
broadband outside the major cities is pitiful: where I'm located I have
to consider myself lucky to get 512Kb/s. I'll likely not be able to get
more for decades.

>> Nov 22 22:47:51 hades err: pulseaudio[6242]: socket-server.c: bind(): Address already in use
>> Nov 22 22:47:51 hades err: pulseaudio[6242]: module.c: Failed to load  module "module-native-protocol-tcp" (argument: "auth-anonymous=1"): initialization failed.
>> Nov 22 22:47:51 hades err: pulseaudio[6242]: module-gconf.c: pa_module_load() failed
>> Nov 22 22:47:51 hades err: pulseaudio[6242]: socket-server.c: socket(PF_INET6): Address family not supported by protocol
>> Nov 22 22:47:51 hades err: pulseaudio[6242]: socket-server.c: bind(): Address already in use
>> Nov 22 22:47:51 hades err: pulseaudio[6242]: module.c: Failed to load  module "module-esound-protocol-tcp" (argument: "auth-anonymous=1"): initialization failed.
>> Nov 22 22:47:51 hades err: pulseaudio[6242]: module-gconf.c: pa_module_load() failed
>> Nov 22 22:47:51 hades err: pulseaudio[6242]: module.c: Module "module-zeroconf-publish" should be loaded once at most. Refusing to load.
>> Nov 22 22:47:51 hades err: pulseaudio[6242]: module-gconf.c: pa_module_load() failed
>> 
>> It's almost as if it's reading the config file twice or something.
>
> Is it possible that you activated the network modules in GConf via
> paprefs and are loading them at the same time from the config file?
> The comments in default.pa explicitly warn you about this.

Oh bugger. You're right, they do. I've commented it out and that's much
happier now. Sorry, stupid of me: I think that uncommenting was hanging
around from the time when I was trying to get a per-user PulseAudio
config working.

btw, another reason to run a systemwide pulseaudio configuration: if
you're using MPD, either you do that or you mess about with
authentication in order to allow the MPD user to talk to *any* user's
PulseAudio instance, and you *still* don't get any sound when they've
logged out of X... (plus, when they log out, mpd loses its PulseAudio
connection as PA shuts down).

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