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

[Lennart Poettering]

On Mon, 26.11.07 00:35, Nix (nix at esperi.org.uk) wrote:

> > 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-
> 

Arrg. emu10k1 again. Seems to be a very problematic sound card. mmap
with that card seems to be broken in many ways. 

This thread on the ALSA ML deals with a related problem:

http://mailman.alsa-project.org/pipermail/alsa-devel/2007-November/004419.html

It might be a good idea to contact the ALSA devs about this. I cannot
really do this from here, since I don't have access to an emu10k1.

> > 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?

hrtimers are only available on x86 right now on release kernels, not
even x86-64. And a HPET would be good too.

Or install some useful distro, such as Fedora, which includes hrtimer
support for x86-64, too.

> 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).

Doesn't adding the mpd user to the "pulse-access" group fix your problem?

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4