Problem using WavPack codec (wavpackenc) for recording with splitmuxsink

[amotl]

Hi there,

at [1], it was suggested by weef to make the lossless WavPack codec available to the Saraswati recording subsystem. The corresponding GStreamer element would be wavpackenc.

With kind regards,
Andreas.

[1] https://community.hiveeyes.org/t/developing-saraswati-a-robust-multi-channel-audio-recording-transmission-and-storage-system/924/19

[amotl]

Unfortunately, on my workstation running macOS, despite having gst-plugins-good==1.18.4 installed, it looks like the wavpackenc element is not available. There is no corresponding file like libgstwavpack.dylib at /usr/local/Cellar/gst-plugins-good/1.18.4/lib/gstreamer-1.0.

$ gst-inspect-1.0 | grep -i wavpack
typefindfunctions: audio/x-wavpack-correction: wvc
typefindfunctions: audio/x-wavpack: wv, wvp
libav:  avenc_wavpack: libav WavPack encoder
audioparsers:  wavpackparse: Wavpack audio stream parser

When using avenc_wavpack instead, GStreamer croaks with:

gst_parse_error: could not link avenc_wavpack0 to muxer (3)

[amotl]

However, on a Linux installment, following [1], wavpackenc seems to be available:

$ docker run -it --rm amd64/debian:buster-slim bash
$ apt-get update
$ apt-get install --yes libgstreamer1.0 gstreamer1.0-tools gstreamer1.0-alsa gstreamer1.0-plugins-base gstreamer1.0-plugins-good

$ gst-inspect-1.0 | grep -i wavpack
wavpack:  wavpackenc: Wavpack audio encoder
wavpack:  wavpackdec: Wavpack audio decoder
audioparsers:  wavpackparse: Wavpack audio stream parser
typefindfunctions: audio/x-wavpack-correction: wvc
typefindfunctions: audio/x-wavpack: wv, wvp

[1] https://github.com/hiveeyes/saraswati#debian-based-systems

[amotl]

In order to approach this, I used a Docker setup.

Observations

First, I verified that I was able to record something successfully with saraswati record --channel="testdrive source=autoaudiosrc". Despite this warning message, it worked when using the FLAC codec.

gst-resource-error-quark: Could not open audio device for recording. (5) (gstalsasrc.c(748): gst_alsasrc_open (): /GstAlsaSrc:autoaudiosrc0-actual-src-als:
Recording open error on device 'default': No such file or directory)

However, when using the WavPack codec, as outlined through #8, GStreamer emits another warning:

gst_parse_error: Delayed linking failed. (7) (./grammar.y(510): gst_parse_no_more_pads (): /GstPipeline:pipeline0/GstWavpackEnc:wavpackenc0:
failed delayed linking some pad of GstWavpackEnc named wavpackenc0 to pad  audio_0 of GstSplitMuxSink named muxer)

and it looks like the pipeline doesn't get into "playing" mode.

Outlook

We will have to check the patch #8 on a machine with a real ALSA setup.

With kind regards,
Andreas.

[amotl]

Further observations

We will have to check the patch #8 on a machine with a real ALSA setup.

In order to rule out hardware issues, I quickly checked using audiotestsrc:

saraswati record --channel="testdrive source=audiotestsrc wave=3 freq=200"

The observations were the same: While it works with the FLAC codec, it croaks with WavPack in the same manner as outlined above. So, the origin of the error is probably in the layout of the pipeline, where the wavpackenc element seems to need some special treatment to fit into a pipeline using splitmuxsink. I believe I also observed similar issues with other elements in combination with splitmuxsink.

More details

Those are the full pipeline definitions we are using for this scenario.

Works

audiotestsrc wave=3 freq=200 ! audioconvert ! queue ! flacenc ! flactag ! flacparse ! muxer.audio_0 splitmuxsink name=muxer muxer=matroskamux max-size-time=300000000000 max-files=9999

Failure 1

audiotestsrc wave=3 freq=200 ! audioconvert ! queue ! wavpackenc ! muxer.audio_0 splitmuxsink name=muxer muxer=matroskamux max-size-time=300000000000 max-files=9999

Failure 2

When adding wavpackparse, it croaks earlier, already when assembling the pipeline

gst_parse_error: could not link wavpackparse0 to muxer (3)

audiotestsrc wave=3 freq=200 ! audioconvert ! queue ! wavpackenc ! wavpackparse ! muxer.audio_0 splitmuxsink name=muxer muxer=matroskamux max-size-time=300000000000 max-files=9999

[amotl]

On [1,2], I see there have been a number of fixes to splitmuxsink in recent versions of gstreamer-plugins-good>=1.18. However, on the Linux machine I used for testing (amd64/debian:buster-slim), there is only GStreamer 1.14.4.

We will have to check that again using a more recent GStreamer installment on Linux.

[1] https://build.opensuse.org/package/view_file/openSUSE:Factory/gstreamer-plugins-good/gstreamer-plugins-good.changes?expand=0
[2] https://fossies.org/linux/gst-plugins-good/ChangeLog

[amotl]

We will have to check that again using a more recent GStreamer installment on Linux.

Same error when using amd64/debian:bullseye-slim, bringing in GStreamer 1.18.4.

2021-06-21 17:49:43,993 [saraswati.recorder] WARNING: Pipeline warning: gst_parse_error: Delayed linking failed. (7) (gst/parse/grammar.y(540): gst_parse_no_more_pads (): /GstPipeline:pipeline0/GstWavpackEnc:wavpackenc0:
failed delayed linking some pad of GstWavpackEnc named wavpackenc0 to pad  audio_0 of GstSplitMuxSink named muxer)