GNOME Bugzilla – Bug 721740
general stream error with alsasink iec958 audio/x-ac3 passtrough
Last modified: 2018-11-03 11:27:48 UTC
I got a general stream error when trying pasuspender -- gst-launch-1.0 filesrc location=www_lynnemusic_com_surround_test.ac3 ! ac3parse ! alsasink device='iec958:CARD=PCH,DEV=0' On Ubuntu Precise 64 bit and Intel hda ALC887-VA sound. This is the output with --gst-debug=alsa:5 -v 0:00:00.021135527 17580 0x8daf00 DEBUG alsa gstalsaplugin.c:71:plugin_init: binding text domain gst-plugins-base-1.0 to locale dir /usr/local/share/locale 0:00:00.021304832 17580 0x8daf00 DEBUG alsa gstalsasink.c:253:gst_alsasink_init:<GstAlsaSink@0x8ec1b0> initializing alsasink 0:00:00.021504834 17580 0x8daf00 DEBUG alsa gstalsasink.c:286:gst_alsasink_getcaps:<alsasink0> device not open, using template caps 0:00:00.021592933 17580 0x8daf00 DEBUG alsa gstalsasink.c:286:gst_alsasink_getcaps:<alsasink0> device not open, using template caps Setting pipeline to PAUSED ... 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 0:00:00.025361246 17580 0x7b2cf0 DEBUG alsa gstalsa.c:182:gst_alsa_detect_formats:<alsasink0> skipping non-raw format 0:00:00.025370231 17580 0x7b2cf0 DEBUG alsa gstalsa.c:182:gst_alsa_detect_formats:<alsasink0> skipping non-raw format 0:00:00.025373826 17580 0x7b2cf0 DEBUG alsa gstalsa.c:182:gst_alsa_detect_formats:<alsasink0> skipping non-raw format 0:00:00.025377105 17580 0x7b2cf0 DEBUG alsa gstalsa.c:182:gst_alsa_detect_formats:<alsasink0> skipping non-raw format 0:00:00.025384538 17580 0x7b2cf0 DEBUG alsa gstalsa.c:49:gst_alsa_detect_rates:<alsasink0> Min. rate = 32000 (32000) 0:00:00.025389965 17580 0x7b2cf0 DEBUG alsa gstalsa.c:50:gst_alsa_detect_rates:<alsasink0> Max. rate = 192000 (192000) 0:00:00.025395106 17580 0x7b2cf0 DEBUG alsa gstalsa.c:383:gst_alsa_detect_channels:<alsasink0> Min. channels = 2 (2) 0:00:00.025399140 17580 0x7b2cf0 DEBUG alsa gstalsa.c:384:gst_alsa_detect_channels:<alsasink0> Max. channels = 2 (2) 0:00:00.025408356 17580 0x7b2cf0 DEBUG alsa gstalsa.c:463:gst_alsa_open_iec958_pcm:<alsasink0> Generated device string "iec958:CARD=PCH,DEV=0:{AES0 0x02 AES1 0x82 AES2 0x00 AES3 0x02}" 0:00:00.025428547 17580 0x7b2cf0 WARN alsa conf.c:4606:parse_args: alsalib error: Parameter DEV must be an integer 0:00:00.025437385 17580 0x7b2cf0 WARN alsa conf.c:4711:snd_config_expand: alsalib error: Parse arguments error: Invalid argument 0:00:00.025443189 17580 0x7b2cf0 WARN alsa pcm.c:2239:snd_pcm_open_noupdate: alsalib error: Unknown PCM iec958:CARD=PCH,DEV=0:{AES0 0x02 AES1 0x82 AES2 0x00 AES3 0x02} 0:00:00.025457422 17580 0x7b2cf0 DEBUG alsa gstalsa.c:469:gst_alsa_open_iec958_pcm:<alsasink0> failed opening IEC958 device: Invalid argument 0:00:00.025462405 17580 0x7b2cf0 INFO alsa gstalsasink.c:318:gst_alsasink_getcaps:<alsasink0> returning caps audio/x-raw, format=(string){ S16LE, S32LE }, layout=(string)interleaved, rate=(int)[ 32000, 192000 ], channels=(int)2, channel-mask=(bitmask)0x0000000000000003 ERROR: from element /GstPipeline:pipeline0/GstAc3Parse:ac3parse0: GStreamer encountered a general stream error. Additional debug info: gstbaseparse.c(3188): gst_base_parse_loop (): /GstPipeline:pipeline0/GstAc3Parse:ac3parse0: streaming stopped, reason not-negotiated ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... /GstPipeline:pipeline0/GstAc3Parse:ac3parse0.GstPad:src: caps = NULL Freeing pipeline ...
Can one confirm that my command should work? Has one a working setup? My original task was playing a DVD with Totem/Pulseaudio and AC3 Sound (Dolby Digital LED lit on my amp) I have also filed an Launchpad bug https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1264609 Currently I have a working mplayer setup with pasuspender -- mplayer -mouse-movements -nocache dvdnav:// -ao alsa:device=iec958=1.0 -ac hwac3 After a lot of investigations, it turns out that there a some problems that prevents the gst pileline from working, 1. Passtroug probing fails with -EBUSSY The alsasink tries to open the same device twice for probing IEC958 parameter. IMHO this is not necessary, since the non-audio parameter is just a flag, defined in the IEC958 standard. So any "spdiff" and "iec958" alsa device is able to set this flag. Probing for the connected amp capabilities is not possible because spdiff has no feedback channel. 2. Generating the device string with parameters fails if the device has already parameters. alsasink always adds an additional colon this is wrong if there is already one. 3. The ac3 stream has 0 channels, this leads to a devision by zero. I will prepare a patches for 1 and 2. And I need help to fix 3. Any ideas?
I tested this some time ago and it worked back then, and I'm not aware of any changes that may have broken this. Will try and re-test.
Created attachment 265612 [details] [review] patch for generating iec958 device string
Thank Tim-Philipp you for your help! Here is the patch, fixing 2. I have took the working solution from mplayer and moved it to glib functions.
Created attachment 265614 [details] [review] Patch, fixing -EBUSSY This patch is on top of the previous patch, fixing 1.
Unfortunately the two patches are not making the pipeline work. I have managed to make it work with: diff --git a/ext/alsa/gstalsasink.c b/ext/alsa/gstalsasink.c index 19dbd8b..fdf896d 100644 --- a/ext/alsa/gstalsasink.c +++ b/ext/alsa/gstalsasink.c @@ -684,7 +684,11 @@ set_sw_params: static gboolean alsasink_parse_spec (GstAlsaSink * alsa, GstAudioRingBufferSpec * spec) { - /* Initialize our boolean */ + alsa->rate = GST_AUDIO_INFO_RATE (&spec->info); + alsa->channels = GST_AUDIO_INFO_CHANNELS(&spec->info); + alsa->buffer_time = spec->buffer_time; + alsa->period_time = spec->latency_time; + alsa->access = SND_PCM_ACCESS_RW_INTERLEAVED; alsa->iec958 = FALSE; switch (spec->type) { @@ -796,16 +800,13 @@ alsasink_parse_spec (GstAlsaSink * alsa, GstAudioRingBuffe case GST_AUDIO_RING_BUFFER_FORMAT_TYPE_MPEG: alsa->format = SND_PCM_FORMAT_S16_BE; alsa->iec958 = TRUE; + alsa->channels = 2; + GST_AUDIO_INFO_CHANNELS(&spec->info) = 2; break; default: goto error; } - alsa->rate = GST_AUDIO_INFO_RATE (&spec->info); - alsa->channels = GST_AUDIO_INFO_CHANNELS (&spec->info); - alsa->buffer_time = spec->buffer_time; - alsa->period_time = spec->latency_time; - alsa->access = SND_PCM_ACCESS_RW_INTERLEAVED; if (spec->type == GST_AUDIO_RING_BUFFER_FORMAT_TYPE_RAW && alsa->channels < 9 gst_audio_ring_buffer_set_channel_positions (GST_AUDIO_BASE_SINK
But this is an ugly hack and finally leads to ac3 stream interpreted as PCM. Funny sound ;-) I hope that one can lead me to a right solution. I have not fully understood who and when alsa->iec958 is set. It looks like alsasink_parse_spec() is the only function writes this flag. But gdb tells me that there must be an other function. I am also wandering how this code works. alsa->iec958 is read, before it is set from alsasink_parse_spec below. If I change the two code blocks, My Amp switches to Dolby Digital, but still no Sound. gst_alsasink_prepare (GstAudioSink * asink, GstAudioRingBufferSpec * spec) { ... if (alsa->iec958) { snd_pcm_close (alsa->handle); alsa->handle = gst_alsa_open_iec958_pcm (GST_OBJECT (alsa), alsa->device); if (G_UNLIKELY (!alsa->handle)) { goto no_iec958; } } if (!alsasink_parse_spec (alsa, spec)) goto spec_parse;
I've had the same bug on similar Intel hardware, but I've moved beyond this point. I've got working audio out by applying the patches above, then disabling the byte swap path in gst_alsasink_write. At this point it's not clear to me how the sink should correctly detect the endianness that the driver requires for iec958 data.
Hello, I have same kind of bug on sti hardware (little endian architecture)... Concerning byte swap, i have logged Bug 757258. Here is my analysis on the point, i hope that can help to solve the issue: To check pass-through support alsasink try to open pcm device with AES arguments: "hw:0,0:{AES0 0x02 AES1 0x82 AES2 0x00 AES3 0x02}" alsa device types that support AES arguments are hdmi and iec958 (visible in /usr/share/alsa/pcm). But in this case, formats supported are IEC958_SUBFRAME_LE and IEC958_SUBFRAME_BE. Alsasink seems support only S16_LE and S16_BE (gst_alsa_detect_formats support only "audio/x-raw" format for alsa_device). So not compatible... here is one way to support pass-through: 1) Create a pcm device that supports either S16 format and AES args. In attachment, example of asound.conf file that define a device to support it on my "hw:0,0" device 2) Pass-through caps detection seems bugged. alsasink tries to open iec958 pcm device while it is already opened in pcm raw mode. Fix should consists in closing pcm device before reopen it with AES parameters. Proposed patch in attachment: alsasink-fix-iec958-format-detection.patch => Using this implementation i'm able to play PCM on "hw:0,0" device and pass-through on "myiec958" device.
Created attachment 314502 [details] [review] alsasink: fix iec958 format detection
Created attachment 314503 [details] asoun.conf example
-- 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-plugins-base/issues/102.