i.MX8M Plus - SPDIF Protocol Implementation Example

[ramkrish]

Hi Team,

Could someone pls suggest how to implement and validate SPDIF Protocol in i.MX8M plus?

[yipingwang]

Use the existing Linux ALSA Audio XCVR / S/PDIF driver on i.MX8M Plus; you normally do not implement the S/PDIF protocol from scratch. The i.MX8M Plus Audio XCVR supports eARC, ARC, and S/PDIF modes, and the Linux S/PDIF support exposes one playback device for Tx and one capture device for Rx through ALSA. 

Suggested implementation path:

Enable the kernel driver Enable:

CONFIG_SND_IMX_SPDIF

Menu path:

Copy

Device Drivers

  -> Sound card support

    -> Advanced Linux Sound Architecture

      -> ALSA for SoC audio support

        -> SoC Audio for Freescale i.MX CPUs

          -> SoC Audio support for i.MX boards with S/PDIF

The documented DT bindings are under Documentation/devicetree/bindings/sound/fsl,spdif.txt and Documentation/devicetree/bindings/sound/imx-audio-spdfif.txt . 

• Configure the device tree For i.MX8M Plus, use the xcvr audio block and enable the sound card / DAI link. A representative configuration is:

sound-xcvr {

    compatible = "fsl,imx-audio-card";

    model = "imx-audio-xcvr";

    pri-dai-link {

        link-name = "XCVR PCM";

        cpu {

            sound-dai = <&xcvr>;

        };

    };

};

&xcvr {

    #sound-dai-cells = <0>;

    pinctrl-names = "default";

    pinctrl-0 = <&pinctrl_xcvr>;

    status = "okay";

};

For Tx pin muxing, one documented example uses MX8MP_IOMUXC_SPDIF_TX__AUDIOMIX_SPDIF1_OUT . 

• Check board routing / jumpers If using the NXP audio board, set the physical routing for the intended S/PDIF path. For i.MX8M Plus, J1500=1-2 routes the coaxial connector to i.MX8M Plus, and J1500=4-5 routes the optical connector to i.MX8M Plus.  If routing through CPLD / HDMI card, J2511=1-3 is documented as “i.MX 8M Plus to CPLD to HDMI card.” 

• Use ALSA / IEC958 correctly The S/PDIF Tx driver supports 32, 44.1, and 48 kHz sample rates, with S16_LE and S24_LE formats; for 24-bit output, the file must use 32 bits per channel frame with only the 24 LSBs valid.  If the path expects IEC958 subframes rather than raw PCM, do the PCM-to-IEC958 conversion in user space, for example using an ALSA PCM plugin. 

Validation steps:

aplay -l

arecord -l

Use these to identify the S/PDIF playback / capture card and device IDs. The documentation shows the S/PDIF device appearing as an ALSA card such as imxspdif [imx-spdif], device 0: S/PDIF PCM . 

Tx validation:

aplay -D hw:<card_id>,<pcm_id> audio48k24S.wav

The reference validation method uses an external optical S/PDIF receiver, such as an M-Audio Transit USB sound card with WaveLab, then records the stream externally and plays it back to check correctness. 

Rx validation:

arecord -D hw:<card_id>,<pcm_id> -c 2 -d 20 -r 48000 -f S24_LE record.wav

The sample rate passed to arecord must match the incoming S/PDIF stream sample rate.  For Rx, the application flow is to open the S/PDIF Rx PCM device, wait for the internal DPLL to lock to the input bit stream, get the input sample rate, set channel / format / rate parameters, then prepare and trigger capture. 

For protocol-level checks, use:

iecset -c <card_id>

iecset is the standard utility documented for setting or dumping IEC958 status bits, and the driver also exposes channel-status handling through the ALSA control interface. 

For i.MX8M Plus EVK-style validation, NXP also documents loopback-style Linux testing using the imxaudioxcvr card, for example recording from imxaudioxcvr and playing to wm8960audio :

arecord -Dsysdefault:CARD=imxaudioxcvr -c2 -r48000 -fS32_LE -twav | \

aplay -Dsysdefault:CARD=wm8960audio

In short: enable the i.MX S/PDIF / XCVR ALSA driver, configure the xcvr device tree and board routing, then validate Tx/Rx with aplay , arecord , iecset , and an external optical/coax S/PDIF source or sink.

[ramkrish]

Hi Yipingwang,

Could you please guide me with any reference schematics to implement SPDIF in Simplest way.

[yipingwang]

For the simplest i.MX 8M Plus S/PDIF implementation, use the i.MX Audio Board / MCIMX8M-AUD as the closest NXP reference hardware, not the base i.MX 8M Plus EVK alone. The audio board is documented as supporting i.MX 8M Plus and providing S/PDIF I/O with RCA and TOSLINK connectors, with TOSLINK support up to 192 kHz.

Recommended simple approach:

• Use optical S/PDIF first if possible

• Easiest hardware path: i.MX8MP SPDIF_OUT → optical TOSLINK transmitter module.

• For receive: optical TOSLINK receiver module → i.MX8MP SPDIF_IN .

• This avoids coaxial 75 Ω line-drive, transformer/coupling, and grounding concerns.

• Use the i.MX 8M Plus S/PDIF pins through IOMUX

• The i.MX 8M Plus audio subsystem includes SPDIF input and output .

• The reference manual shows IOMUX options for AUDIOMIX_SPDIF1_OUT and AUDIOMIX_SPDIF1_IN on selectable pads.

• In Linux, the corresponding IOMUX definitions include MX8MP_IOMUXC_SPDIF_TX__AUDIOMIX_SPDIF_OUT and MX8MP_IOMUXC_SPDIF_RX__AUDIOMIX_SPDIF_IN .

• If you need coaxial RCA

• Do not treat the SoC pin like a direct RCA line driver.

• Add the proper 75 Ω S/PDIF coax output network / coupling per the selected transmitter/interface circuit.

• Optical is usually the simpler and safer first implementation.

• Reference material to look at

• MCIMX8M-AUD / i.MX Audio Board : best NXP reference for S/PDIF I/O with RCA and TOSLINK on the i.MX 8M family.

• i.MX 8M Plus Reference Manual : pinmux / IOMUX setup for AUDIOMIX_SPDIF1_IN and AUDIOMIX_SPDIF1_OUT .

• i.MX 8M Plus datasheet : S/PDIF timing parameters are documented, including clock high/low timing.

For the simplest design, route AUDIOMIX_SPDIF1_OUT/IN to optical TOSLINK modules and use the MCIMX8M-AUD as the NXP reference point for S/PDIF I/O behavior.

[ramkrish]

Hi @yipingwang

1.Can I loop back SPDIF TX RX directly without any optical TOSLINK Module?
2.Can I loop back optical TOSLINK Module using optical cables?
3.Any End device is required for optical TOSLINK Modules?

[yipingwang]

1. Can I loop back S/PDIF TX/RX directly without optical TOSLINK?

Yes, if you mean electrical S/PDIF loopback . On i.MX8M Plus, the S/PDIF receiver has a bypass option for direct transfer of the S/PDIF input signal to the S/PDIF transmitter, and the reference manual describes the path as SPDIFIN → SPDIFOUT SELECT MUX → SPDIFOUT .

So for protocol/software validation, prefer:

• Internal/bypass loopback if supported by your driver/register setup.
• Or external electrical loopback from SPDIF_TX to SPDIF_RX , if your board exposes both signals and the electrical levels/termination are suitable.

Do not treat this as optical validation. The i.MX8MP S/PDIF pins are electrical; TOSLINK is only the optical physical layer.

2. Can I loop back optical TOSLINK modules using optical cables?

Yes. Use:

i.MX8MP SPDIF_TX pin → optical TOSLINK TX module → optical cable → optical TOSLINK RX module → i.MX8MP SPDIF_RX pin

NXP audio-board material describes S/PDIF I/O with RCA connectors for coaxial communication and TOSLINK connectors for optical communication . Another NXP board example shows separate optical receiver modules and optical transmitter modules used for S/PDIF, e.g. GP1F32R receiver modules and a GP1F32T transmitter module .

This validates more of the real physical path than direct electrical loopback: TX electrical output, optical transmitter, optical cable, optical receiver, and RX input.

3. Is an end device required for optical TOSLINK modules?

For a loopback test back into i.MX8MP RX , no external end audio device is strictly required. The “end device” is effectively the i.MX8MP S/PDIF receiver path.

For TX-only validation or to hear audio, yes — you need an S/PDIF sink such as:

• optical S/PDIF DAC,
• AV receiver,
• S/PDIF analyzer,
• USB audio interface with optical input.

NXP support material states that S/PDIF is a data stream, and if the sink is S/PDIF, you need a device that receives S/PDIF and converts it to an audible format .

Recommended validation sequence:

• First validate i.MX8MP software path with internal/bypass or short electrical loopback.

• Then validate board-level optical path with TOSLINK TX module → optical cable → TOSLINK RX module.

• Finally validate interoperability with a real S/PDIF sink/analyze