Paplay

[SoniEx2]

$ apulse paplay /usr/share/sounds/alsa/Front_Center.wav 
1497902330.166 [apulse 23899] F pa_proplist_new (void)
1497902330.166 [apulse 23899] Z pa_channel_map_init_extend
1497902330.166 [apulse 23899] Z pa_channel_map_compatible
1497902330.166 [apulse 23899] F pa_proplist_new (void)
1497902330.166 [apulse 23899] Z pa_utf8_filter
1497902330.166 [apulse 23899] F pa_proplist_sets p=0xad8a10, key=media.format, value=(null)
Segmentation fault (core dumped)

Being able to use paplay would help debugging.

(PS: Any docs on how to read this debug output?)

[i-rinat]

paplay

paplay and other utilities, built from PulseAudio sources, depend on libpulsecommon-10.0.so. That's an internal library, part of the implementation. Library name changes with every release, and it's not actually designed to be binary-compatible. No one is expected to link with it except PulseAudio utilities or libraries. I tried to implement some of the functions back in the days of PulseAudio 5: there is still libpulsecommon-5.0.so binary. And if I memories right, parec was even working. Now current PulseAudio version is 10, and it parec doesn't work even if I rename library to make it happy. Some symbol is missing.

PulseAudio version varies between distributions. And so probably vary their internal symbols. One can say, parec and paplay are the hardest applications to support. So, I'd rather avoid trying to catch up with internal symbols. It's pointless, as a new release will break things again.

As for testing audio output, I'd use mplayer -ao pulse audio.mp3 or mpv --ao=pulse audio.mp3. They should work.

[SoniEx2]

libpulsecommon shouldn't be an issue:

$ ldd `which paplay`
    linux-vdso.so.1 (0x00007ffcfb0ab000)
    libpulse.so.0 => /usr/lib/libpulse.so.0 (0x00007f32c9842000)
    libpulsecommon-10.0.so => /usr/lib/pulseaudio/libpulsecommon-10.0.so (0x00007f32c95bd000)
    libsndfile.so.1 => /usr/lib/libsndfile.so.1 (0x00007f32c9345000)
    libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f32c9127000)
    libc.so.6 => /usr/lib/libc.so.6 (0x00007f32c8d82000)
    libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0x00007f32c8b32000)
    libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f32c892e000)
    libm.so.6 => /usr/lib/libm.so.6 (0x00007f32c861c000)
    libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f32c83f3000)
    libsystemd.so.0 => /usr/lib/libsystemd.so.0 (0x00007f32c9bdf000)
    libasyncns.so.0 => /usr/lib/libasyncns.so.0 (0x00007f32c81ed000)
    librt.so.1 => /usr/lib/librt.so.1 (0x00007f32c7fe5000)
    libFLAC.so.8 => /usr/lib/libFLAC.so.8 (0x00007f32c7d6d000)
    libogg.so.0 => /usr/lib/libogg.so.0 (0x00007f32c7b66000)
    libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0x00007f32c7939000)
    libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2 (0x00007f32c7686000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f32c9a93000)
    libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f32c7482000)
    libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f32c727c000)
    libresolv.so.2 => /usr/lib/libresolv.so.2 (0x00007f32c7066000)
    libcap.so.2 => /usr/lib/libcap.so.2 (0x00007f32c6e62000)
    liblzma.so.5 => /usr/lib/liblzma.so.5 (0x00007f32c6c3c000)
    liblz4.so.1 => /usr/lib/liblz4.so.1 (0x00007f32c6a28000)
    libgcrypt.so.20 => /usr/lib/libgcrypt.so.20 (0x00007f32c6719000)
    libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0x00007f32c6504000)

Since it's just part of the pulse client (libpulse package). Is there anything that stops using apulse with pulseaudio's libpulsecommon?

[i-rinat]

Since it's just part of the pulse client (libpulse package)

...and apulse shadows libraries from that package.

Is there anything that stops using apulse with pulseaudio's libpulsecommon?

Probably not. Since it was something internal to PulseAudio's libpulse, I didn't even try.