GNOME Bugzilla – Bug 757258
gstalsasink: iec61937 (Non-linear PCM bitstreams) not correctly working
Last modified: 2018-11-03 11:43:07 UTC
Created attachment 314333 [details] iec61937 incoherent endianness in playload I'm trying to enable the x-ac3 passtrough for sti platform. This platform is little endian. Applying patch described in Bug 721740, I'm facing endianness issue. I have detected 2 problems: 1) gstalsa.c: gst_audio_iec61937_payload Issue seems introduced in https://bugzilla.gnome.org/show_bug.cgi?id=678021 Some source code still under "#if G_BYTE_ORDER == G_BIG_ENDIAN" while another part tests the endianness provided as parameter. => patch proposed to solve the issue : iec61937 incoherent endianness in playload 2)gstalsasink.c: set_hwparams format detected can be S16_LE or S16_BE. Bytes swapp should depend on platform endianness but also output indianness => Patch proposed to solve the issue: alsasink: endianess fix for iec61937 With this both patches I'm able to play on hw (S16_LE) and plughw (S16_BE) alsa devices. Please notice that i have tried to not impact big endian architecture. But i tested only with little endian architecture... An extra question is: Are all codec big endian formated? If not, it seems that something is missing to take into account the source endianness in case of pass through.
Created attachment 314334 [details] [review] alsasink endianess fix for iec61937
Created attachment 314498 [details] [review] alsasink endianess fix for iec61937 Improve "alsasink endianess fix for iec61937" patch
I rename the ticket to put all iec61937 related patches in same ticket patch set contain 5 patches for following corrections: - Endianness issue for little endian architecture - Iec958 device detection - Iec958 Hw_param channels need to be forced to stereo - alsa->iec958 is tested before set in prepare.
Created attachment 315183 [details] iec61937 patch set
Comment on attachment 315183 [details] iec61937 patch set Please attach patches seperatly. Zip file cannot be commented. If you feel like this is a lot of work, consider using git-bz.
Created attachment 317330 [details] [review] 0001-alsasink-endianess-fix-for-iec61937
Created attachment 317331 [details] [review] 0002-iec61937-incoherent-endianness-in-payload
Created attachment 317332 [details] [review] 0003-alsasink-fix-iec958-format-detection
Created attachment 317333 [details] [review] 0004-iec61937-force-hw_param-channels-to-stereo
Created attachment 317334 [details] [review] 0005-iec61937-set-iec958-boolean-before-use-it
Arun might have some opinions on this
Review of attachment 317330 [details] [review]: ::: ext/alsa/gstalsasink.c @@ +451,3 @@ alsa->format = SND_PCM_FORMAT_S16_LE; + /* swap needed if system is big endian */ + alsa->need_swap = (G_BYTE_ORDER == G_BIG_ENDIAN); Does not seem correct. We ask the driver for BE, I guess that means we have negotiated BE. The reason we'd have to swap is not because of our CPU type, but because what we have miss-match what we have configured. I didn't read the entire file, please clarify. The comment might be the one you forgot to update.
By default alsasink_parse_spec function sets format to SND_PCM_FORMAT_S16_BE for IEC pass through ( AC3, EAC3...). Then, the test of the supported format is done in set_hwparams: > if (snd_pcm_hw_params_set_format (alsa->handle, params, alsa->format) < 0) { > alsa->format = SND_PCM_FORMAT_S16_LE; SND_PCM_FORMAT_S16_BE not supported => set it to SND_PCM_FORMAT_S16_LE >- alsa->need_swap = TRUE; alsa format is Little, so swap only if CPU is BIG. >+ /* swap needed if system is big endian */ >+ alsa->need_swap = (G_BYTE_ORDER == G_BIG_ENDIAN); Regards Arnaud
Hello, Any news? Please tell me is something is missing. Regards Arnaud
(In reply to Arnaud Pouliquen from comment #14) > Hello, > Any news? Please tell me is something is missing. > > Regards > Arnaud Hi Arnaud, It seems I have same issue you mentioned above while trying to passthough audio/x-ac3 via hdmi audio card, The patches above looks reasonable for me. So I'd like to know whether your audio/x-ac3 passthough routinue is workable or not now with above patches? Thanks Lyon
Hi Lyon, I sent patch since a long time now. but nice to see that someone else is facing the issue and that my patches can help :) When i worked on this topics it was worked fine on my platform with these patches. I was able to play audio/x-ac3 in pass-through while selecting the hdmi alsa device and in pcm while selecting the alsa hw pcm device. Regards Arnaud
(In reply to Arnaud Pouliquen from comment #16) > Hi Lyon, > > I sent patch since a long time now. but nice to see that someone else is > facing the issue and that my patches can help :) > > When i worked on this topics it was worked fine on my platform with these > patches. > > I was able to play audio/x-ac3 in pass-through while selecting the hdmi alsa > device and in pcm while selecting the alsa hw pcm device. > > Regards > Arnaud Thanks Arnaud, that is a good news. I haven't applied your patches yet but I was doing some similar modification while I was facing similar issues above (audio card busy (double open), endianess issue and channel issue) However, seems no audio be heard from my receiver yet. I dumped out the ringbuffer data in gst_alsa_write(), suppose the data should be ac3 raw data encapsulated with IEC-61937 format, right? But when I compared the dumped data with the output of "ac3parse ! avmux_spdif ! filesink " (the avmux_spdif output data is in iec61937 format (I compared it with my colleague's another framework with same ac3 file in iec937 output, they are the same.)) , the ringbuffer data is not quite the same though. Anyway, might somewhere of my modification is not correct, I will apply your patches and see the result, Thanks again for your kindly help. Thanks Lyon
Hi Arnaud and Lyon, These patches definitely look worth upstreaming. Could you rebase them against current master ? Thanks
Hi Edward, I just tried, Arnaud's patches could be successfully applied to the master (5ad841e5ff094a484a06274476a2ae1a89a67e18) It would be good they could be upstreamed. BTW, Arnaud and Edward, I still cannot get sound from my AV receiver side after I applied the patches. The ringbuffer data I dumped from gst_alsasink_write() seems not match the data from "ac3parse ! avmux_spdif ! " output of iec61937 format. Did I miss anything else? Any hint or suggestion would be really appreciated. Thanks Lyon
Hi, I switched to another domain, so no more setup to help you... On my side i used gst-play or gst-launch to generate the pipe. drawback of this solution is that you have to well configure the Alsa .asoundrc to support AES devices ( this is also perhaps your issue... try to use iecset) I used following kind of command to test the pass-through: gst-play-1.0 "file.ac3" --audiosink="alsasink device=surround40" gst-launch-1.0 filesrc location=./file.ac3 ! queue ! audio/x-ac3 ! alsasink device=myhdmi Then you can dump the .dot the GST graph to have an overview of the pipe... Another test to validate the alsa driver is to use ffmpeg ffmpeg -i file.ac3 -acodec copy -f spdif - | ffmpeg -f s16le -ac 2 -ar 48000 -i - -acodec copy -f wav file.wav iecset audio off aplay -D hw:0,0 file.wav Sorry to not be able to help you anymore, but really to old for my brain. Regards Arnaud
Hi Arnaud, Thanks for the kind suggestion and information. That will be helpful. I do change the AES parameter setting (not using the parameter in gstalsa.c) and using the configure default value in alsa configure (somehow our audio driver not support device open with AES parameter in the device name) I will do more investigating :) Thanks Lyon
Extra information, than can also help... Try "aplay -L" command on your console. And check you have some "hdmi", "surround<xx>" or "spdif" defined. these devices are specific alsa devices used by gstreamer to determine pass-trough capability. for this Gstreamer tries to open an alsa device with some AES<x> args. By default alsa hardware device (hw:X,Y) does not support it, so you need to create alsa plugin devices. you can have a look here on a way to define this kind of devices: https://patchwork.kernel.org/patch/9703167/
My audio device listed as below: # aplay -l **** List of PLAYBACK Hardware Devices **** card 0: wm8524audio [wm8524-audio], device 0: HiFi wm8524-hifi-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: imxspdif [imx-spdif], device 0: S/PDIF PCM snd-soc-dummy-dai-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 3: imxaudiohdmi [imx-audio-hdmi], device 0: imx8 hdmi hdmi-hifi.0-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 I used hw:3 as the alsasink device. Then I tried iecset tools you mentioned in your last comment. # iecset -Dhw:3 control "IEC958 Playback Default" (index -1) not found but for hw:1 # iecset -Dhw:1 Mode: consumer Data: audio Rate: 44100 Hz Copyright: permitted Emphasis: 50/15us Category: PCM coder Original: 1st generation Clock: 1000 ppm I guess maybe I didn't set the right device ? Will do more test. Really thanks for the extra information ~
aplay -l ( lower case for the l), list the pcm hardware device aplay -L ( upper case for the L) list the pcm devices. gstreamer does not use the iec control but only this PCM device with the AES args to check pass-through capability
Hi, Arnaud Good news here, The audio pass through finally managed to work... (What embarrassing here is I tried with PCM output with wav file and my AV receiver still no response, then I realize maybe something wrong with the AV receiver. And when I borrowed another AV receiver, it all works fine then -_-b )
I will continue to check other format like eac3, see if it works :)
Hi Lyon, Very nice new. Please comment when your finish your test, to confirm or not the patches validity Regards Arnaud
Hi Arnaud, The patches works well for AC3 pass through from my test. (Fixed previous device double open issue, multi-channel issue and byte endianess issue) For eac3 streams, the pipeline works, but seems no sound be heard yet. (seems data has been written) 0:00:02.058492442 5137 0x2f802370 LOG alsa gstalsasink.c:1049:gst_alsasink_write:<alsasink0> received audio samples buffer of 24576 bytes 0:00:02.090333124 5137 0x2f802370 DEBUG alsa gstalsasink.c:1066:gst_alsasink_write:<alsasink0> written 1536 frames out of 1536 0:00:02.090489484 5137 0x2f802370 LOG alsa gstalsasink.c:1049:gst_alsasink_write:<alsasink0> received audio samples buffer of 24576 bytes 0:00:02.122332445 5137 0x2f802370 DEBUG alsa gstalsasink.c:1066:gst_alsasink_write:<alsasink0> written 1536 frames out of 1536 will continue work on this eac3 issue. 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-plugins-base/issues/238.