Currently, the audio device enumeration in AESinkALSA.cpp contains code that seems to be specially tailored to Wandboard. It uses hardcoded device names ("imxspdif", "imxhdmisoc" and "sgtl5000audio") and grabs "sysdefault" devices. Especially the latter creates a problem with passthrough (see #53). This happens because the AES0..AES3 parameters are not passed on to the driver and some amps therefore treat the encoded audio stream (DTS,AC3) as PCM.
I think we should remove the Wandboard-specific code and go back to the XBMC default handling. This, however, requires that the distros that run our XBMC need to supply suitable ALSA configuration files. I.e. ones that define the "iec958" and "hdmi" audio devices as expected by XBMC.
The problem with this approach is, that it breaks existing functionality. At least for some people. Any thoughts on this ?
Currently, the audio device enumeration in AESinkALSA.cpp contains code that seems to be specially tailored to Wandboard. It uses hardcoded device names ("imxspdif", "imxhdmisoc" and "sgtl5000audio") and grabs "sysdefault" devices. Especially the latter creates a problem with passthrough (see #53). This happens because the AES0..AES3 parameters are not passed on to the driver and some amps therefore treat the encoded audio stream (DTS,AC3) as PCM.
I think we should remove the Wandboard-specific code and go back to the XBMC default handling. This, however, requires that the distros that run our XBMC need to supply suitable ALSA configuration files. I.e. ones that define the "iec958" and "hdmi" audio devices as expected by XBMC.
The problem with this approach is, that it breaks existing functionality. At least for some people. Any thoughts on this ?