[Bug 757258] New: gstalsasink: byte swap issue for little endian architecture
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Wed Oct 28 09:22:25 PDT 2015
https://bugzilla.gnome.org/show_bug.cgi?id=757258
Bug ID: 757258
Summary: gstalsasink: byte swap issue for little endian
architecture
Classification: Platform
Product: GStreamer
Version: unspecified
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gst-plugins-base
Assignee: gstreamer-bugs at lists.freedesktop.org
Reporter: arnaud.pouliquen at st.com
QA Contact: gstreamer-bugs at lists.freedesktop.org
GNOME version: ---
Created attachment 314333
--> https://bugzilla.gnome.org/attachment.cgi?id=314333&action=edit
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.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
More information about the gstreamer-bugs
mailing list