GNOME Bugzilla – Bug 739800
Static when playing audio at high bitrate/sample rate
Last modified: 2017-07-12 11:05:29 UTC
If you try to play audio from a wav or flac at a bitrate higher than 16, and a sample rate higher than 44.1khz, there will be a bit of ticking static at the beginning. This doesn't occur with ordinary 16/44 files. This is pretty easy to reproduce. You can use something like Sushi or Gnome-Music or the player of your choice that uses Gstreamer. Or just playbin. If you don't have a flac or wav at the bitrate/sample rate I'm talking about, you can make one easily. You can get a wav if you don't have one using a variety of methods, possibly flac at the cli, or audacity or whatever you want. Just use sox on the wav: $ sox song.wav -b 24 -r 96k song_upsampled.wav Just try to play it and each time it will start with a bit of static. I'm not sure if this is confined to the sampling rate, or the bitrate, or is both combined. You can tweak the sox command to narrow it down if it's an issue. I think it's the sampling rate though. I'm using the latest Gstreamer in Debian Jessie (unstable)--1.4.3.
Created attachment 290222 [details] debug log
I've tried this with current git, and I'm not hearing any static. flac -d of an existing file, upsampled with your sox command line, and played with gst-launch-1.0 playbin. I'm getting the float resampler, same as your log. You mentioned playbin, can you confirm you're hearing hte static with just gst-launch-1.0 playbin uri=file:///path/to/wav ? Is this obviously audible ? Does it happen all the time, and, if not, how repeatable is it ? Does the upsampled wav play fine with a non gst player ?
In answer to your questions: Yes, it always happens at the start of any such song. It happens every time a song with higher sampling/bitrates than 16/44 is played. Yes, the wav plays fine in VLC, for example. I should also point out that I have a non-standard audio setup. I think most people are using junky onboard audio. I have the M-Audio Transit. It sits at the end of a 12-ft USB cable. Unfortunately I am not confident that the Linux driver support is entirely up to par compared to basic onboard audio.
If it works with, eg, VLC, it probably isn't that, but it can be checked: gst-launch-1.0 playbin uri=file:///path/to/the/file audio-sink='autoaudiosink' This should use your audio setup. gst-launch-1.0 playbin uri=file:///path/to/the/file audio-sink='wavenc ! filesink location=/tmp/out.wav' This will instead write a wav file with the output that gstreamer decoded. It can then be played with, eg, VLC. If the static appears, it's a problem with gstreamer. If not, then... the mystery continues.
There was no static.
Some other commands that might give clues: gst-launch-1.0 audiotestsrc wave=4 ! audio/x-raw,rate=96000 ! pulsesink gst-launch-1.0 audiotestsrc wave=4 ! audio/x-raw,rate=96000 ! alsasink These two play silent audio at high bitrate with two different sinks. This removes decoders/resamplers from the equation and might finger one of the sinks in particular.
The distortion happens with pulsesink but not alsasink. I had suspected this could be due to some issue involving Pulse, but I didn't understand why VLC wouldn't have the same problem since they're both talking to Pulse.
I've tried this on various systems, among one using a usb headset and can't reproduce it. Brandon, can you try to play such a high sampling rate file via paplay - paplay can play everything that libsndfile can decode (e.g. wave files). You can also play a way file directly on alsa via aplay. This could help us to get more data.
Hi, paplay and aplay using a 16/96 wav results in no static, while playbin does produce static.
Does the static go away if you run one of the offending piplines with this env var set: ORC_CODE=backup ?
ORC_CODE=backup makes no difference.
Are you able to run pulseaudio itself with this ? I think it should be enough to kill the daemon and run gst with ORC_CODE=backup, which should autospawn a new daemon. I'm thinking the problem might be the one fixed here: http://lists.freedesktop.org/archives/pulseaudio-discuss/2015-January/022905.html
I tried pulseaudio --kill and then set ORC_CODE=backup and ran gst-launch-1.0 audiotestsrc wave=4 ! audio/x-raw,rate=96000 ! pulsesink but the static is still there.
Not sure why I did not ask that before, but... Can you run this simple pipeline with valgrind to see if anything interesting pops up ?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!
Output of command requested in comment 14 (tick-tick happens at Pipeline is PREROLLING): $ valgrind gst-launch-1.0 audiotestsrc wave=4 ! audio/x-raw,rate=96000 ! pulsesink ==20572== Memcheck, a memory error detector ==20572== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==20572== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==20572== Command: gst-launch-1.0 audiotestsrc wave=4 ! audio/x-raw,rate=96000 ! pulsesink ==20572== --20572-- WARNING: Serious error when reading debug info --20572-- When reading debug info from /lib/x86_64-linux-gnu/ld-2.21.so: --20572-- Ignoring non-Dwarf2/3/4 block in .debug_info --20572-- WARNING: Serious error when reading debug info --20572-- When reading debug info from /lib/x86_64-linux-gnu/ld-2.21.so: --20572-- Last block truncated in .debug_info; ignoring --20572-- WARNING: Serious error when reading debug info --20572-- When reading debug info from /lib/x86_64-linux-gnu/ld-2.21.so: --20572-- parse_CU_Header: is neither DWARF2 nor DWARF3 nor DWARF4 --20572-- WARNING: Serious error when reading debug info --20572-- When reading debug info from /lib/x86_64-linux-gnu/libc-2.21.so: --20572-- Ignoring non-Dwarf2/3/4 block in .debug_info --20572-- WARNING: Serious error when reading debug info --20572-- When reading debug info from /lib/x86_64-linux-gnu/libc-2.21.so: --20572-- Last block truncated in .debug_info; ignoring --20572-- WARNING: Serious error when reading debug info --20572-- When reading debug info from /lib/x86_64-linux-gnu/libc-2.21.so: --20572-- parse_CU_Header: is neither DWARF2 nor DWARF3 nor DWARF4 --20572-- WARNING: Serious error when reading debug info --20572-- When reading debug info from /lib/x86_64-linux-gnu/libm-2.21.so: --20572-- Ignoring non-Dwarf2/3/4 block in .debug_info --20572-- WARNING: Serious error when reading debug info --20572-- When reading debug info from /lib/x86_64-linux-gnu/libm-2.21.so: --20572-- Last block truncated in .debug_info; ignoring --20572-- WARNING: Serious error when reading debug info --20572-- When reading debug info from /lib/x86_64-linux-gnu/libm-2.21.so: --20572-- parse_CU_Header: is neither DWARF2 nor DWARF3 nor DWARF4 --20572-- WARNING: Serious error when reading debug info --20572-- When reading debug info from /lib/x86_64-linux-gnu/librt-2.21.so: --20572-- Ignoring non-Dwarf2/3/4 block in .debug_info --20572-- WARNING: Serious error when reading debug info --20572-- When reading debug info from /lib/x86_64-linux-gnu/librt-2.21.so: --20572-- Last block truncated in .debug_info; ignoring --20572-- WARNING: Serious error when reading debug info --20572-- When reading debug info from /lib/x86_64-linux-gnu/librt-2.21.so: --20572-- parse_CU_Header: is neither DWARF2 nor DWARF3 nor DWARF4 --20572-- WARNING: Serious error when reading debug info --20572-- When reading debug info from /lib/x86_64-linux-gnu/libdl-2.21.so: --20572-- Ignoring non-Dwarf2/3/4 block in .debug_info --20572-- WARNING: Serious error when reading debug info --20572-- When reading debug info from /lib/x86_64-linux-gnu/libdl-2.21.so: --20572-- Last block truncated in .debug_info; ignoring --20572-- WARNING: Serious error when reading debug info --20572-- When reading debug info from /lib/x86_64-linux-gnu/libdl-2.21.so: --20572-- parse_CU_Header: is neither DWARF2 nor DWARF3 nor DWARF4 --20572-- WARNING: Serious error when reading debug info --20572-- When reading debug info from /lib/x86_64-linux-gnu/libnsl-2.21.so: --20572-- Ignoring non-Dwarf2/3/4 block in .debug_info --20572-- WARNING: Serious error when reading debug info --20572-- When reading debug info from /lib/x86_64-linux-gnu/libnsl-2.21.so: --20572-- Last block truncated in .debug_info; ignoring --20572-- WARNING: Serious error when reading debug info --20572-- When reading debug info from /lib/x86_64-linux-gnu/libnsl-2.21.so: --20572-- parse_CU_Header: is neither DWARF2 nor DWARF3 nor DWARF4 --20572-- WARNING: Serious error when reading debug info --20572-- When reading debug info from /lib/x86_64-linux-gnu/libresolv-2.21.so: --20572-- Ignoring non-Dwarf2/3/4 block in .debug_info --20572-- WARNING: Serious error when reading debug info --20572-- When reading debug info from /lib/x86_64-linux-gnu/libresolv-2.21.so: --20572-- Last block truncated in .debug_info; ignoring --20572-- WARNING: Serious error when reading debug info --20572-- When reading debug info from /lib/x86_64-linux-gnu/libresolv-2.21.so: --20572-- parse_CU_Header: is neither DWARF2 nor DWARF3 nor DWARF4 Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstPulseSinkClock ^Chandling interrupt. Interrupt: Stopping pipeline ... Execution ended after 0:00:13.767364840 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... ==20572== ==20572== HEAP SUMMARY: ==20572== in use at exit: 618,830 bytes in 2,439 blocks ==20572== total heap usage: 50,173 allocs, 47,734 frees, 9,806,145 bytes allocated ==20572== ==20572== LEAK SUMMARY: ==20572== definitely lost: 16,384 bytes in 1 blocks ==20572== indirectly lost: 0 bytes in 0 blocks ==20572== possibly lost: 4,828 bytes in 63 blocks ==20572== still reachable: 586,658 bytes in 2,293 blocks ==20572== of which reachable via heuristic: ==20572== length64 : 320 bytes in 8 blocks ==20572== newarray : 1,584 bytes in 19 blocks ==20572== suppressed: 0 bytes in 0 blocks ==20572== Rerun with --leak-check=full to see details of leaked memory ==20572== ==20572== For counts of detected and suppressed errors, rerun with: -v ==20572== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Thanks. This is with what version of GStreamer?
This is 1.6.3
I'm not really sure what to do about this. I believe the issue is real, it's just that it's really difficult to debug without being able to reproduce it locally, and it's also unclear if the issue is on the GStreamer side or pulseaudio side. I think I'll have to close this for now since I don't see anyone being able to investigate further, sorry.