GNOME Bugzilla – Bug 724509
audioconvert: outputs silence when converting certain mono caps to certain other mono caps
Last modified: 2014-02-18 11:32:00 UTC
Created attachment 269342 [details] testcase based on apsrc-stream2.c This is (kind of) a follow up of bug 723331 (meaning mostly that the patch from there is applied). Tested on https://github.com/rheit/zdoom/blob/master/wadsrc/static/sounds/dssecret.flac, but if that file is converted to ogg by oggenc, the silence is reproducible. ( though that leads to funny results of its own: the encoded file has still 22491 frames (and plays on its own (that is in a media player) correctly), but the produced raw audio in case of unset caps, supposedly F32LE is only 45056 bytes long and sounds cut off ) There's a chance I've botched the caps, but if they're correct, setting them results in the file being converted into silence. As long as the line with gst_app_sink_set_caps is commented out, the file is being played, but the format might not be correct (leading to distorted sound).
The problem seems to be the channel-mask=0 that gets set for the i=0 / channels=1 case. Without it, you get proper data alright. It looks like it might be a bug in audioconvert: gstaudioconvert.c:739:gst_audio_convert_fixate_caps:<conv> fixated othercaps to audio/x-raw, layout=(string)interleaved, rate=(int)11025, format=(string)S16LE, channels=(int)1, channel-mask=(bitmask)0x0000000000000000 gstaudioconvert.c:753:gst_audio_convert_set_caps:<conv> incaps audio/x-raw, format=(string)S8, layout=(string)interleaved, rate=(int)11025, channels=(int)1, outcaps audio/x-raw, layout=(string)interleaved, rate=(int)11025, format=(string)S16LE, channels=(int)1, channel-mask=(bitmask)0x0000000000000000 audioconvert.c:620:audio_convert_prepare_context: depth in 8, out 16 audioconvert.c:634:audio_convert_prepare_context: using no dither and noise shaping gstchannelmix.c:641:gst_channel_mix_setup_matrix: Matrix for 1 -> 1: { { 0.000000 } } That mixmatrix is what results in everything being 0.
And it shouldn't really use a mixmatrix in the first place here, but it does apparently: audioconvert.c:671:audio_convert_prepare_context: in default 0, mix passthrough 0, out default 0
Created attachment 269491 [details] [review] patch that seems to fix the problem Thanks for the hints, Tim. Thanks to them I found the trouble spot. As it was said on the chat, proper handling of "channel-mask" is bit imprecise in the docs, but in code too. This patch fixes the problem, but I'm not sure how compiler safe it is (relies on that gst_structure_get call being done first).
...though converted ogg is still cut short...
Thanks for the patch! Would be great if you could supply the patch in 'git format-patch' format next time, that makes applying it easier for us. I've also added a secondary sanity check/fix in audioconvert: commit 6c6619a66922bac0c343c4a5623d5bdb322f0e92 Author: Tim-Philipp Müller <tim@centricular.com> Date: Tue Feb 18 10:42:04 2014 +0000 audioconvert: never do mixing for 1->1 channel conversions MONO and NONE position are the same, for example, but in general there isn't much to do here for such a conversion. Fixes problem in audioconvert, which would end up using a mixmatrix when converting between different mono format because it thinks MONO positioning is different from unpositioned channels, which is not the case in this special case. The mixmatrix would end up being 0.0 so audioconvert would convert to silence samples. https://bugzilla.gnome.org/show_bug.cgi?id=724509 commit 5496d09eb42fa63d725f0a01ac6c7584126bc5da Author: Rafał Mużyło <galtgendo@o2.pl> Date: Tue Feb 18 10:32:46 2014 +0000 audio: map channels=1,channel-mask=0 to MONO instead of NONE Fixes problem in audioconvert, which would end up using a mixmatrix when converting between different mono format because it thinks MONO positioning is different from unpositioned channels, which is not the case in this special case. The mixmatrix would end up being 0.0 so audioconvert would convert to silence samples. https://bugzilla.gnome.org/show_bug.cgi?id=724509
Please file a separate bug for the ogg issue btw :)
(In reply to comment #6) > Please file a separate bug for the ogg issue btw :) :sigh: