GNOME Bugzilla – Bug 796466
failed to link avmux_spdif link with alsasink for ac3 passthrough
Last modified: 2018-11-03 12:58:57 UTC
Hi, I was trying to realize ac3 audio passthrough via hdmi by a certain pipeline with avmux_spdif. By pipeline: "gst-launch-1.0 filesrc location= 5.1_de.ac3 ! ac3parse ! avmux_spdif ! filesink location= ac3.spdif" I managed to dump out the encapsulated ac3 (iec61958) format. Then I was trying to link avmux_spdif with alsasink Noticing avmux_spdif src caps is "application/x-gst-av-spdif", which alsasink not supported, so I modified avmux_spdif src caps with "audio/x-ac3, framed=true" However seems I still met problem when trying to output the data via alsasink below is some log with GST_DEBUG=audiobasesink:6,2 Setting pipeline to PAUSED ... 0:00:00.182977808 [335m 3646[00m 0x3c8bb190 [33;01mWARN [00m [00m basesrc gstbasesrc.c:3583:gst_base_src_start_complete:<filesrc0>[00m pad not activated yet Pipeline is PREROLLING ... /GstPipeline:pipeline0/GstAc3Parse:ac3parse0.GstPad:src: caps = audio/x-ac3, framed=(boolean)true, rate=(int)48000, channels=(int)6, alignment=(string)frame /GstPipeline:pipeline0/avmux_spdif:avmux_spdif0.GstPad:audio_0: caps = audio/x-ac3, framed=(boolean)true, rate=(int)48000, channels=(int)6, alignment=(string)frame 0:00:00.186149288 [335m 3646[00m 0x3c867280 [32;01mFIXME [00m [00m basesink gstbasesink.c:3145:gst_base_sink_default_event:<alsasink0>[00m stream-start event without group-id. Consider implementing group-id handling in the upstream elements 0:00:00.186471848 [335m 3646[00m 0x3c867280 [37mDEBUG [00m [00m audiobasesink gstaudiobasesink.c:1197:gst_audio_base_sink_preroll:<alsasink0>[00m ringbuffer in wrong state 0:00:00.186508208 [335m 3646[00m 0x3c867280 [33;01mWARN [00m [00m audiobasesink gstaudiobasesink.c:1198:gst_audio_base_sink_preroll:<alsasink0>[00m error: sink not negotiated. 0:00:00.186702488 [335m 3646[00m 0x3c867280 [37mDEBUG [00m [00m audiobasesink gstaudiobasesink.c:1197:gst_audio_base_sink_preroll:<alsasink0>[00m ringbuffer in wrong state ERROR: from element /GstPipeline:pipeline0/GstAlsaSink:alsasink0: The stream is in the wrong format. 0:00:00.186732608 [335m 3646[00m 0x3c867280 [33;01mWARN [00m [00m audiobasesink gstaudiobasesink.c:1198:gst_audio_base_sink_preroll:<alsasink0>[00m error: sink not negotiated. Additional debug info: ../../../../git/gst-libs/gst/audio/gstaudiobasesink.c(1198): gst_audio_base_sink_preroll (): /GstPipeline:pipeline0/GstAlsaSink:alsasink0: sink not negotiated. ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... Do anyone meet similar issue when trying to use avmux_spdif to passthrough ac3 via alsasink? Any hint will be appreciated for this issue Thanks Lyon
This is not how alsasink currently supports passthrough, as far as I know. avmux_spdif should not be needed, and we don't support it. ac3parse ! alsasink might/should work.
(In reply to Tim-Philipp Müller from comment #1) > This is not how alsasink currently supports passthrough, as far as I know. > avmux_spdif should not be needed, and we don't support it. > > ac3parse ! alsasink might/should work. Then who will do the encapsulating of IEC 61937 for the ac3 data? Suppose ac3 data need to be encapsulated and then send out as passthrough data, which can be recognized and decoded at receiver side? or my understanding is not correct?
It will be done by the audio sink, there are some utility functions in libgstaudio.
Hi Tim, thanks for your hint. So I tried with command line: gst-launch-1.0 filesrc locaiton=5.1_de.ac3 ! ac3parse ! alsasink device=hw:3 --gst-debug=5 and it will report "no such device" error: 0:00:00.142809846 4343 0x272e78f0 DEBUG alsa gstalsa.c:472:gst_alsa_open_iec958_pcm:<alsasink0> Generated device string "hw:3:{AES0 0x02 AES1 0x82 AES2 0x00 AES3 0x02}" 0:00:00.143829486 4343 0x272e78f0 WARN alsa pcm_hw.c:1713:_snd_pcm_hw_open: alsalib error: Invalid value for card 0:00:00.143927526 4343 0x272e78f0 DEBUG alsa gstalsa.c:478:gst_alsa_open_iec958_pcm:<alsasink0> failed opening IEC958 device: No such device Then I modified "devstr", without adding :{AES0 0X02....} (Are these string necessary to be added ?) This time the device can be recognized, however, it reports device busy: 0:00:00.483679220 3462 0xec5f8f0 DEBUG alsa gstalsa.c:474:gst_alsa_open_iec958_pcm:<alsasink0> Generated device string "hw:3" 0:00:00.484194620 3462 0xec5f8f0 WARN alsa pcm_hw.c:1602:snd_pcm_hw_open: alsalib error: open '/dev/snd/pcmC3D0p' failed (-16): Device or resource busy 0:00:00.484306460 3462 0xec5f8f0 DEBUG alsa gstalsa.c:481:gst_alsa_open_iec958_pcm:<alsasink0> failed opening IEC958 device: Device or resource busy Is there anything I miss or some patch we need to include? I see in this ticket Bug 721740, similar EBUSY error return, do we miss anything or patch here (I am using GST 1.14.0) ? Thanks Lyon
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-libav/issues/39.