[pulseaudio-discuss] [PATCH] esound auth-ip-acl fix

Nix nix at esperi.org.uk
Mon Oct 6 01:32:34 PDT 2008

On 4 Oct 2008, Lennart Poettering said:

> On Thu, 02.10.08 21:18, Nix (nix at esperi.org.uk) wrote:
>> > Is it possible that your card can do either surround sound XOR full
>> > duplex? i.e. either stereo in + stereo out XOR surround out + nothing
>> > in?
>> I don't have a clue if it can do surround sound. I only have two
>> speakers,
>> so I certainly don't *want* surround sound. How do I find out?
> For PA to do Surround you have to configure it to do so. By default
> only do stereo.

I haven't configured it to do so, so its refusal to start source and
sink at the same time must have some other explanation.

>> This is the underlying cause of the 'ALSA doesn't work for me' thing I
>> moaned about long ago and then failed to do anything about. Here's some
>> log output with a pile of extra debugging statements dropped into PA and
>> alsa-lib to show what's going on. (There are debugging statements after
>> the ioctl() decorated with `Setting hw params', but it gets an -ENOTTY,
>> so they are never reached.)
> What driver is this again?

SB Live, emu10k1... which is... *unset* in my .config?! How the hell is
my system producing any sound at all? The running system says it must be
built in, but every .config I can find has it turned off! Yet
/proc/asound/cards says plainly that it's there:

 0 [Live           ]: EMU10K1 - SBLive! [CT4620]
                      SBLive! [CT4620] (rev.4, serial:0x211102) at 0xd400, irq 16

I think I'll do a kernel rebuild and see what happens if I turn the
right driver on. (This is simultaneously embarrassing and bizarre, but I
think we must assume it actually *was* enabled when this kernel was

>> I'm afraid the log is quite long, and the output comes from a time
>> before I fixed the esound bug so that's going wrong as well. (Ignore the
>> hrtimer stuff: as far as I can tell my 2001-vintage hardware isn't
>> capable of giving me hrtimers. Maybe I should upgrade.)
> Hmm, hrtimers are actually support by everything that has an HPET. And
> I think systems have that since quite a while.

This system is 2001-vintage:

| #define _GNU_SOURCE 1
| #include <stdio.h>
| #include <time.h>
| int main (void)
| {
|     struct timespec ts;
|     if (clock_getres (CLOCK_MONOTONIC, &ts) < 0)
|         perror ("No monotonic clock");
|     else
|         printf ("sec: %li; nsec: %li\n", ts.tv_sec, ts.tv_nsec);
|     if (clock_getres (CLOCK_REALTIME, &ts) < 0)
|         perror ("No monotonic clock");
|     else
|         printf ("sec: %li; nsec: %li\n", ts.tv_sec, ts.tv_nsec);
|     return 0;
| }

sec: 0; nsec: 999848
sec: 0; nsec: 999848

hrtimers are turned on in the kernel, but have no effect.

(I'd upgrade, but it's so bloody much effort for a hardware ignoramus
and this system still basically works and does what I need it to.
PulseAudio has never skipped, even under extreme load (make -j 255
levels of load). I find myself wondering just what the people who *are*
experiencing skips are doing.)

> Hmm, I am not sure hat exactly is going on with your system, but I am
> pretty sure that's a bug in the ALSA driver. Please bring this up on
> alsa-devel.

Will do.

`Not even vi uses vi key bindings for its command line.' --- PdS

More information about the pulseaudio-discuss mailing list