SIGILL on aarch64 when setting volume
Describe your issue
$ gst-launch-1.0 -v -m audiotestsrc ! volume volume=0.5 ! fakesink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Got message #7 from element "fakesink0" (state-changed): GstMessageStateChanged, old-state=(GstState)null, new-state=(GstState)ready, pending-state=(GstState)void-pending;
Got message #8 from element "volume0" (state-changed): GstMessageStateChanged, old-state=(GstState)null, new-state=(GstState)ready, pending-state=(GstState)void-pending;
Got message #9 from element "audiotestsrc0" (state-changed): GstMessageStateChanged, old-state=(GstState)null, new-state=(GstState)ready, pending-state=(GstState)void-pending;
Got message #10 from element "pipeline0" (state-changed): GstMessageStateChanged, old-state=(GstState)null, new-state=(GstState)ready, pending-state=(GstState)paused;
Got message #12 from element "volume0" (state-changed): GstMessageStateChanged, old-state=(GstState)ready, new-state=(GstState)paused, pending-state=(GstState)void-pending;
Got message #15 from pad "audiotestsrc0:src" (stream-status): GstMessageStreamStatus, type=(GstStreamStatusType)create, owner=(GstElement)"\(GstAudioTestSrc\)\ audiotestsrc0", object=(GstTask)"\(GstTask\)\ audiotestsrc0:src";
Got message #16 from element "audiotestsrc0" (state-changed): GstMessageStateChanged, old-state=(GstState)ready, new-state=(GstState)paused, pending-state=(GstState)void-pending;
Got message #17 from pad "audiotestsrc0:src" (stream-status): GstMessageStreamStatus, type=(GstStreamStatusType)enter, owner=(GstElement)"\(GstAudioTestSrc\)\ audiotestsrc0", object=(GstTask)"\(GstTask\)\ audiotestsrc0:src";
Got message #18 from element "pipeline0" (stream-start): GstMessageStreamStart, group-id=(uint)1;
Got message #22 from pad "audiotestsrc0:src" (property-notify): GstMessagePropertyNotify, property-name=(string)caps, property-value=(GstCaps)"audio/x-raw\,\ format\=\(string\)S16LE\,\ layout\=\(string\)interleaved\,\ rate\=\(int\)44100\,\ channels\=\(int\)1";
/GstPipeline:pipeline0/GstAudioTestSrc:audiotestsrc0.GstPad:src: caps = audio/x-raw, format=(string)S16LE, layout=(string)interleaved, rate=(int)44100, channels=(int)1
Got message #24 from pad "volume0:src" (property-notify): GstMessagePropertyNotify, property-name=(string)caps, property-value=(GstCaps)"audio/x-raw\,\ format\=\(string\)S16LE\,\ layout\=\(string\)interleaved\,\ rate\=\(int\)44100\,\ channels\=\(int\)1";
/GstPipeline:pipeline0/GstVolume:volume0.GstPad:src: caps = audio/x-raw, format=(string)S16LE, layout=(string)interleaved, rate=(int)44100, channels=(int)1
Got message #25 from pad "fakesink0:sink" (property-notify): GstMessagePropertyNotify, property-name=(string)caps, property-value=(GstCaps)"audio/x-raw\,\ format\=\(string\)S16LE\,\ layout\=\(string\)interleaved\,\ rate\=\(int\)44100\,\ channels\=\(int\)1";
/GstPipeline:pipeline0/GstFakeSink:fakesink0.GstPad:sink: caps = audio/x-raw, format=(string)S16LE, layout=(string)interleaved, rate=(int)44100, channels=(int)1
Got message #26 from pad "volume0:sink" (property-notify): GstMessagePropertyNotify, property-name=(string)caps, property-value=(GstCaps)"audio/x-raw\,\ format\=\(string\)S16LE\,\ layout\=\(string\)interleaved\,\ rate\=\(int\)44100\,\ channels\=\(int\)1";
/GstPipeline:pipeline0/GstVolume:volume0.GstPad:sink: caps = audio/x-raw, format=(string)S16LE, layout=(string)interleaved, rate=(int)44100, channels=(int)1
Got message #30 from element "fakesink0" (tag): GstMessageTag, taglist=(taglist)"taglist\,\ description\=\(string\)\"audiotest\\\ wave\"\;";
[1] 1587 illegal hardware instruction (core dumped) gst-launch-1.0 -v -m audiotestsrc ! volume volume=0.5 ! fakesink
Expected Behavior
Setting the volume of a pipeline shouldn't cause the application to crash.
Observed Behavior
The application crashed with SIGILL.
Setup
- Operating System: Arch Linux ARM aarch64
- Device: Raspberry Pi 5
- GStreamer Version: 1.22.9, installed via pacman
-
Command line: Any command line involving the
volume
element
Steps to reproduce the bug
See the command line above for an example.
In my case it causes a crash in mopidy whenever the volume is changed via the software mixer.
How reproducible is the bug?
Always, and very easy to reproduce.
Screenshots if relevant
N/A
Solutions you have tried
- Using Pipewire instead of Pulseaudio
- Using raw ALSA instead of Pulseaudio
- Disabling the HDMI audio output
- Tried over audio jack, USB audio card and Bluetooth audio
Related non-duplicate issues
https://github.com/mopidy/mopidy/issues/2148