[ANNOUNCE] PulseAudio 0.9.15-test3

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Wed, Feb 25, 2009 at 6:13 PM, Erich Boleyn <erich at uruk.org> wrote:
>
> Greetings all,
>
> I tried building and running the new PulseAudio, and it is getting
> module load failures for the alsa-related modules.
>
> For example, in the "/usr/bin/pulseaudio --dump-modules" command,
> it get the following failures:
>
> ? ? ? ?E: modinfo.c: Failed to open module "/usr/lib64/pulse-0.9.15/modules/module-alsa-card": file not found
> ? ? ? ?E: modinfo.c: Failed to open module "/usr/lib64/pulse-0.9.15/modules/module-alsa-sink": file not found
> ? ? ? ?E: modinfo.c: Failed to open module "/usr/lib64/pulse-0.9.15/modules/module-alsa-source": file not found

Ditto here. I pinged Lennart about this on IRC the other day, but
unfortunately I had to run before I was able to resolve this.

The initial effort suggested by Lennart is to run `strace -eopen` on
pulseaudio, and look through the open() calls for NSFD (No Such File
or Directory). It's gonna have several of them due to the way
resources and libraries are found by searching through a list of
paths, but each unique filename it tries to look up should ultimately
result in a "good" open() call (i.e., no error).

My investigation suggests that it's able to open() these sinks
numerous times, so maybe the problem is that it can't open them when
it really needs to. I'm just not sure without further investigation. I
do have a gut feeling, though, that it has something to do with
libtool and its attempt to resolve the symbols in the modules. When PA
calls lt_dlopenext(), libltdl will bail out as soon as it fails to
resolve a symbol or a link-time library dependency. The problem is
occurring because it bails out with a NULL pointer, and the
lt_dlerror() call indicates "file not found" (which would indicate
that, somewhere along the line, an ENOENT was produced by some code);
but I am skeptical about whether "file not found" really means that as
such, or whether it means "I tried to resolve a symbol, but couldn't".
The string "file not found" is not present in the C library (according
to the `strings` program), so a direct libc call can't be producing
this message. If a libc call (i.e., fopen()) got an error, the errno
would be set so that strerror(ENOENT) yields the text "No such file or
directory". I'm thinking that this problem is unusually difficult to
debug because libltdl is *not* robust in its error reporting!

I'm on Ubuntu 9.04 Alpha, x86_64. What is your platform, out of interest?

I'll keep you posted as to whether I make progress towards resolving
this issue or not.

Thanks,

Sean

>
>
> I could probably do a better job debugging what's wrong, but won't
> have time to look at it for at least a week (crunch at work).
>
> --
> ? ?Erich Stefan Boleyn ? ? <erich at uruk.org> ? ? http://www.uruk.org/
> "Reality is truly stranger than fiction; Probably why fiction is so popular"
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>



[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux