#14 Error accessing sound input from ¨Ia@¨Ia@-widget

audio (2)
David Liontooth

When starting the prebuild deb package version of
xvidcap or gvidcap, I get

"Error accessing sound input from ¨Ia@¨Ia@-widget
Sound disabled!"

In addition, I'm seeing the same error and application
crash as I saw with the 1.1.0 deb package:

When starting to capture in gvidcap I get

"gvidcap: relocation error: gvidcap: undefined symbol:


  • Logged In: YES

    The problem may be that the .deb posted is built for Debian
    stable (woody) and I'm running Debian unstable (sid). When I
    build from the 1.1.1 tarball I don't get the "gvidcap:
    relocation error: gvidcap: undefined symbol: __fixunssfdi"
    error, but the "Error accessing sound input from
    Ia@Ia@-widget Sound disabled!" erro is unchanged.

  • Logged In: YES

    Sound works fine in 1.1.1-rc2 but fails in 1.1.1 final. I've
    tried the deb file, the tarball, and cvs (I had to change
    the reference to sound.h to get it to compile from tarball
    and cvs).

  • Logged In: YES

    I sort of found the source of the "Error accessing sound
    input from Ia@Ia@-widget Sound disabled!" problem -- it's
    some kind of character set translation bug.

    First, the error appears if you leave the value for the
    audio device empty (a normal situation for users who upgrade
    to 1.1.1).

    Second, if you enter the correct value for your audio device
    (say, /dev/dsp0) and save it, you get a similar error, but
    with a new device name -- frequely using non-ascii
    characters, such as ▒onic instead of Ia@Ia@. UTF-8
    problem perhaps?

    Third, there is one value that won't trigger the bug at all
    -- /dev/dsp. In my case, that's a symlink that points to my
    audio device (/dev/dsp0).

    In brief, the workaround for this error is to edit
    ~/.xvidcap.scf and add the following:

    audio_in: /dev/dsp

    If that's not your audio device, make it a symlink to what
    is your audio device.

    I imagine the bug is pretty trivial.

    • status: open --> open-accepted
  • Logged In: YES

    the relocation error is definetely due to the different
    Debian releases
    (stable vs. unstable) I've found references to differences
    in libgcc and
    then smth. about linking against a library built on the one
    and used on
    the other. Since the error only seems to occur with gvidcap,
    I assume
    it's about where the GTK library was built .... not sure
    there, not much
    hope to change it, until sarge stabilizes (wouldn't want to
    upgrade, now)

    the other error was even simpler ... was storing a pointer
    to a non-static
    string instead of using strdup()

    However, while testing this, I found another bug: If you
    open and close
    the preferences dialog a number of times, sometimes you will
    get a
    segfault ...
    leaving this but open till fix for the latter is available.


    • status: open-accepted --> closed-fixed
  • Logged In: YES

    CVS has the other segfault fixed, too. Failed to initalize a
    glist to NULL.