Sound not working and segfaults on Linux Mint 18

[xet7]

@kirbyfan64

Summary

On Linux Mint 18, sound is not working, and trying to click Start and other buttons does exit TSC with segfaults etc. This in on devel branch, and sound also does not work on feature-cegui-0.8 branch - although these errors are from devel branch.

Latest commit in devel branch

commit 51fa178557807a505e65e8242345cd8f55395585
Author: Quintus
Date:   Fri May 6 15:53:30 2016 +0200
    Build tinyclipboard using CMake. Cf. #540.

Screenshot

Translated error messages from Finnish to English

Yhteyskäytäntövirhe = The protocol error
Muistialueen ylitys = Segmentation fault
Yhteys torjuttu = Connection refused
Tiedostoa tai hakemistoa ei ole = No such file or directory
Keskeytetty = Aborted

Installing required packages

To get TSC to compile on Linux Mint 18, using INSTALL.md instructions, I had to change libboost1.55-all-dev => libboost1.58-all-dev, install also build-essential cmake libcegui-mk2-dev, and on main-website directory "sudo gem install bundler && bundle install".

Details of Linux Mint version and kernel

$ cat /etc/issue
Linux Mint 18 Sarah \n \l

$ uname -a
Linux COMPUTERNAME 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Continuing on next post below...

[xet7]

Errors as attachment textfiles, they were too long to copy-paste to comment.

compile.txt TSC-run-otherbuttons-errors.txt TSC-run-Start-error.txt TSC-run-Load-error.txt TSC-run-Authors-error.txt TSC-run-Quit-error.txt

[xet7]

cegui log: cegui-log.txt

[refi64]

Looks like this may be an SFML bug.

@xet7 What happens if you edit audio/audio.cpp and add the following before line 37:

sf::Listener::setGlobalVolume(100.f);

[xet7]

@kirbyfan64

I will try later again with that code change. This comment is still from test done before.

So the previous errors are with sfml-dev that are from Linux Mint 18 packages.

When I previously instead tried to install sfml-dev from git repo source, and tried to compile, I got this error:

/usr/bin/ld: tsc: hidden symbol ”__cpu_model” in targer /usr/lib/gcc/x86_64-linux-gnu/5/libgcc.a(cpuinfo.o) is reference of DSO
/usr/bin/ld: final linking step failed: Wrong value
collect2: error: ld returned 1 exit status
CMakeFiles/tsc.dir/build.make:4261: recipe for target 'tsc' failed
make[2]: *** [tsc] Error 1
CMakeFiles/Makefile2:249: recipe for target 'CMakeFiles/tsc.dir/all' failed
make[1]: *** [CMakeFiles/tsc.dir/all] Error 2
Makefile:149: recipe for target 'all' failed
make: *** [all] Error 2

This is using this SFML commit code on master branch:

commit b1827ddb6d701d7d6f39b1477ae17a9a69b98747
Author: JacksonCoder
Date:   Fri Jun 17 07:10:54 2016 -0600
    Fixed a small typo in the Xcode Template

So I was unable to compile TSC with newest SFML.

Also I got this error when trying to run TSC (previously compiled probably with Linux Mint package SFML):

./bin/tsc: symbol lookup error: /usr/local/lib/libsfml-graphics.so.2.3: undefined symbol: __cpu_model

[refi64]

@xet7 Ahhhh...Looks like an Arch bug, too...

Try configuring TSC with cmake ... -DLINK_LIBRARIES="gcc_s gcc".

[xet7]

@kirbyfan64

Hi, I added that code line to audio.c file on both devel and feature-cegui-0.8 branch, like this:

cAudio_Sound::cAudio_Sound(void)
{
    sf::Listener::setGlobalVolume(100.f);
    m_data = NULL;
    m_resource_id = -1;
}

When compiling devel branch with command:

rm -rf /home/USERNAME/tsc-devel && -DLINK_LIBRARIES="gcc_s gcc" cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/home/USERNAME/tsc-devel .. && make && make install

Compiling does not seem to progress anymore, it has been on last line of the build log for some hours. It has not quit or crashed, and it does not seem to do anything anymore.

When compiling feature-cegui-0.8 branch with this command:

rm -rf /home/USERNAME/tsc-feature-cegui-0.8 && cmake -DLINK_LIBRARIES="gcc_s gcc" -DCMAKE_INSTALL_PREFIX=/home/USERNAME/tsc-feature-cegui-0.8 -DCMAKE_BUILD_TYPE=Debug -DENABLE_EDITOR=OFF -DENABLE_NEW_EDITOR=ON .. && make && make install

Compiling did finish. I forgot to save compiling log, but running tsc logs are included here. It still segfaults.

I'll also try compiling SFML from git repo later. cegui-log-feature-cegui-0.8.txt compile-devel-stuck.txt run2-feature-cegui-0.8.txt run-feature-cegui-0.8.txt

[xet7]

@kirbyfan64

I did not find yet where to add SFML build option -DLINK_LIBRARIES="gcc_s gcc" .

I'll continue later.

[xet7]

@kirbyfan64

I killed make-command that was compiling devel, it exited with these lines of text:

Makefile:419: recipe for target 'all-recursive' failed
CMakeFiles/cegui07.dir/build.make:113: recipe for target 'cegui/src/cegui07-stamp/cegui07-build' failed
make[4]: *** [all-recursive] Stopped
make[2]: *** [cegui/src/cegui07-stamp/cegui07-build] Stopped
/bin/bash: line 9:22744 Stopped              make $local_target
CMakeFiles/Makefile2:141: recipe for target 'CMakeFiles/cegui07.dir/all' failed
make[1]: *** [CMakeFiles/cegui07.dir/all] Stopped
Makefile:2440: recipe for target 'all-recursive' failed
make[5]: *** [all-recursive] Stopped
Makefile:149: recipe for target 'all' failed
make: *** [all] Stopped
Makefile:376: recipe for target 'all-recursive' failed
Stopped
make[3]: *** [all-recursive] Stopped
/bin/bash: line 9:22752 Stopped              make $local_target

[refi64]

@xet7 I'm sorry; I should've been more specific. The option goes with the cmake command, e.g. cmake -D....

The hanging is pretty bizarre, though...

Could you try running TSC as gdb tsc, run it (in non-full-screen mode, unless you want it to hang), and then, when it crashes, enter bt at the prompt and copy the results here? I'm going to try getting Arch Linux myself to repro, but I won't be able to try it until tomorrow or the day after.

[xet7]

@kirbyfan64

Sure I did have that option after cmake command on the right side, I copy-pasted it above wrong.

I'm trying to get this working on Linux Mint 18, I have not used Arch Linux yet.

Attached is gdb log.

gdb-tsc-feature-cegui-0.8.txt

I need to sleep now, I'll continue later.

[refi64]

@xet7 Seems like your OpenAL is configured to use Pulseaudio, but it can't connect to the server. Do you have pulseaudio installed? What happens if you run pulseaudio --start?

[xet7]

@kirbyfan64

$ pulseaudio --start
N: [pulseaudio] main.c: User-configured server at {4603ef0b0eb640e2836974a04d12e5ab}unix:/run/user/1000/pulse/native, which appears to be local. Probing deeper.

$ dpkg -l | grep pulseaudio
ii  gstreamer0.10-pulseaudio:amd64                              0.10.31-3+nmu4ubuntu2~gcc5.1               amd64        GStreamer plugin for PulseAudio
ii  gstreamer1.0-pulseaudio:amd64                               1.8.1-1ubuntu0.1                           amd64        GStreamer plugin for PulseAudio
ii  pulseaudio                                                  1:8.0-0ubuntu3                             amd64        PulseAudio sound server
ii  pulseaudio-module-bluetooth                                 1:8.0-0ubuntu3                             amd64        Bluetooth module for PulseAudio sound server
ii  pulseaudio-module-x11                                       1:8.0-0ubuntu3                             amd64        X11 module for PulseAudio sound server
ii  pulseaudio-utils                                            1:8.0-0ubuntu3                             amd64        Command line tools for the PulseAudio sound server

Sound does work in other apps, Firefox / Chrome / VLC etc.

[refi64]

@xet7 I'm pretty sure at this point that this isn't a TSC bug; it really seems like an issue in your OpenAL installation. What are the contents of /etc/openal/alsoft.conf?

[xet7]

@kirbyfan64

alsoft-conf.txt

[refi64]

@xet7 Can you try changing line 141 of that file to:

drivers = -pulse

[xet7]

@kirbyfan64

I added to that file the line:

## drivers:
#  Sets the backend driver list order, comma-seperated. Unknown backends and
#  duplicated names are ignored. Unlisted backends won't be considered for use
#  unless the list is ended with a comma (e.g. 'oss,' will try OSS first before
#  other backends, while 'oss' will try OSS only). Backends prepended with -
#  won't be considered for use (e.g. '-oss,' will try all available backends
#  except OSS). An empty list means to try all backends.
drivers = -pulse

And rebooted.

Then I started TSC, here's gdb log. TSC does not have sound, other apps do have.

gdb.txt

[Quintus]

This does not look like a TSC bug to me. There's something wrong with SFML here, and/or xet7's setup. xet7, please try to provide a minimal working example by creating a minimal SFML program with sound output from the tutorials on the SFML website.

If our analysis of the problem is correct, then any SFML program is going to exhibit this bug. A minimal SFML example would suffice for a possible bug report upstream.

I do not close this issue yet. If xet7 reports a minimal SFML program produces the problem, then it should be closed.

Vale, Quintus

[eXpl0it3r]

Here's a minimal example to test your audio (haven't compiled it, hope it works):

#include <SFML/Audio.hpp>

int main()
{
    sf::SoundBuffer buffer;
    buffer.loadFromFile("mysoundfile.wav");
    sf::Sound sound(buffer);
    sound.play();
    while(sound.getStatus() == sf::Sound::Playing)
    {
        sf::sleep(sf::seconds(1.f));
    }
}

[xet7]

@eXpl0it3r

Using this test.cpp file:

#include <SFML/Audio.hpp>

int main()
{
    sf::SoundBuffer buffer;
    buffer.loadFromFile("drm.wav");
    sf::Sound sound(buffer);
    sound.play();
    while(sound.getStatus() == sf::Sound::Playing)
    {
        sf::sleep(sf::seconds(1.f));
    }
}

When I try to compile it, I get this error:

$ g++ test.cpp -o test
/tmp/ccIFzn9r.o: In function `main':
test.cpp:(.text+0x26): undefined reference to `sf::SoundBuffer::SoundBuffer()'
test.cpp:(.text+0x63): undefined reference to `sf::SoundBuffer::loadFromFile(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
test.cpp:(.text+0x97): undefined reference to `sf::Sound::Sound(sf::SoundBuffer const&)'
test.cpp:(.text+0xa6): undefined reference to `sf::Sound::play()'
test.cpp:(.text+0xb5): undefined reference to `sf::Sound::getStatus() const'
test.cpp:(.text+0xcc): undefined reference to `sf::seconds(float)'
test.cpp:(.text+0xd4): undefined reference to `sf::sleep(sf::Time)'
test.cpp:(.text+0xe5): undefined reference to `sf::Sound::~Sound()'
test.cpp:(.text+0xf4): undefined reference to `sf::SoundBuffer::~SoundBuffer()'
test.cpp:(.text+0x141): undefined reference to `sf::Sound::~Sound()'
test.cpp:(.text+0x155): undefined reference to `sf::SoundBuffer::~SoundBuffer()'
collect2: error: ld returned 1 exit status

[xet7]

@eXpl0it3r

I have these sfml packages installed on Linux Mint 18 64bit:

$ dpkg -l | grep sfml
ii  libsfml-audio2.3v5:amd64                                    2.3.2+dfsg-1                               amd64        Simple and Fast Multimedia Library - Audio part
ii  libsfml-dev:amd64                                           2.3.2+dfsg-1                               amd64        Simple and Fast Multimedia Library - Development Files
ii  libsfml-graphics2.3v5:amd64                                 2.3.2+dfsg-1                               amd64        Simple and Fast Multimedia Library - Graphics part
ii  libsfml-network2.3v5:amd64                                  2.3.2+dfsg-1                               amd64        Simple and Fast Multimedia Library - Network part
ii  libsfml-system2.3v5:amd64                                   2.3.2+dfsg-1                               amd64        Simple and Fast Multimedia Library - System part
ii  libsfml-window2.3v5:amd64                                   2.3.2+dfsg-1                               amd64        Simple and Fast Multimedia Library - Window part

[eXpl0it3r]

Well you obviously have to link SFML. :wink:

g++ test.cpp -o test -lsfml-audio -lsfml-system

[xet7]

@eXpl0it3r

Ok, now it gives this error:

$ g++ test.cpp -o test -lsfml-audio -lsfml-audio
/usr/bin/ld: /tmp/ccN0qzEV.o: undefined reference to symbol '_ZN2sf7secondsEf'
//usr/lib/x86_64-linux-gnu/libsfml-system.so.2.3: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status

[refi64]

Why did you put -lsfml-audio twice? This should work:

g++ test.cpp -o test -lsfml-audio -lsfml-system

[eXpl0it3r]

I had it written like that by accident. Edited it now.

[xet7]

@eXpl0it3r

I compiled it with that command:

g++ test.cpp -o test -lsfml-audio -lsfml-system

And when running it I got this:

$ ./test
shm_open() failed: No such file or directory
AL lib: (WW) alc_initconfig: Failed to initialize backend "pulse"
shm_open() failed: No such file or directory
ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Protocol error

AL lib: (EE) ALCplaybackAlsa_open: Could not open playback device 'default': Connection refused
Failed to open the audio device
An internal OpenAL call failed in SoundBuffer.cpp(46).
Expression:
   alGenBuffers(1, &m_buffer)
Error description:
   AL_INVALID_OPERATION
   The specified operation is not allowed in the current state.

shm_open() failed: No such file or directory
ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Protocol error

AL lib: (EE) ALCplaybackAlsa_open: Could not open playback device 'default': Connection refused
Failed to open the audio device
An internal OpenAL call failed in SoundBuffer.cpp(265).
Expression:
   alBufferData(m_buffer, format, &m_samples[0], size, sampleRate)
Error description:
   AL_INVALID_OPERATION
   The specified operation is not allowed in the current state.

An internal OpenAL call failed in SoundSource.cpp(37).
Expression:
   alGenSources(1, &m_source)
Error description:
   AL_INVALID_OPERATION
   The specified operation is not allowed in the current state.

An internal OpenAL call failed in SoundSource.cpp(38).
Expression:
   alSourcei(m_source, AL_BUFFER, 0)
Error description:
   AL_INVALID_OPERATION
   The specified operation is not allowed in the current state.

An internal OpenAL call failed in Sound.cpp(104).
Expression:
   alSourcei(m_source, AL_BUFFER, m_buffer->m_buffer)
Error description:
   AL_INVALID_OPERATION
   The specified operation is not allowed in the current state.

An internal OpenAL call failed in Sound.cpp(73).
Expression:
   alSourcePlay(m_source)
Error description:
   AL_INVALID_OPERATION
   The specified operation is not allowed in the current state.

An internal OpenAL call failed in SoundSource.cpp(177).
Expression:
   alGetSourcei(m_source, AL_SOURCE_STATE, &status)
Error description:
   AL_INVALID_OPERATION
   The specified operation is not allowed in the current state.

An internal OpenAL call failed in Sound.cpp(87).
Expression:
   alSourceStop(m_source)
Error description:
   AL_INVALID_OPERATION
   The specified operation is not allowed in the current state.

An internal OpenAL call failed in SoundSource.cpp(60).
Expression:
   alSourcei(m_source, AL_BUFFER, 0)
Error description:
   AL_INVALID_OPERATION
   The specified operation is not allowed in the current state.

An internal OpenAL call failed in SoundSource.cpp(61).
Expression:
   alDeleteSources(1, &m_source)
Error description:
   AL_INVALID_OPERATION
   The specified operation is not allowed in the current state.

[Quintus]

I think we can be fairly certain now that this is not a bug in TSC. @xet7, @eXpl0it3r you should carry this over to the SFML tracker. Please link the resulting ticket here so we can follow it.

I close this now as an upstream issue.

Valete, Quintus

[eXpl0it3r]

Make sure to follow the contribution guidelines. I'd still claim it's some weird driver issue, since OpenAL fails to connect to the device in the first place.

[xet7]

@eXpl0it3r

It seems that today after doing:

pulseaudio --kill
pulseaudio --start

and using laptop internal speakers plays sound correctly with SFML example code.

With TSC compiled today from devel branch, main menu music plays correctly, but selecting menu option causes segfault. I will post separate issue.

[Quintus]

@xet7 Please, report SFML-specific stuff on the SFML tracker, not here, where it is lost for the SFML devs!

(the segfault of TSC of course belongs to our tracker)

[eXpl0it3r]

Please, report SFML-specific stuff on the SFML tracker

No, that's what the forum is for. Since this is by far not a confirmed issue and most likely just some weird driver thing...

[Quintus]

Okay, but definitely the TSC bugtracker is not the correct place. That's all I wanted to point out.