We are using Toradex Colibri IMX6ULL and IMX7D for audio applications. We are using gstreamers for audio playing. While playing audio we are noticed one observation i.e when channels=1 in caps filter for alsasink we are getting word clock is decreased by 10% with the mentioned clock-rate in pipeline. Given below are the details:
For 8KHz:
|MCLK|36.86MHz|
|WCLK|7.112KHz|
|BCLK|128KHz|
For 16KHz:
|MCLK|36.86MHz|
|WCLK|14.22KHz|
|BCLK|256.1KHz|
For 32KHz:
|MCLK|36.86MHz|
|WCLK|28.44KHz|
|BCLK|512KHz|
For 48Khz:
|MCLK|36.86MHz|
|WCLK|42KHz|
|BCLK|768KHz|
These are the Hardware Measured Values. Can Anyone know why like this ?
whereas with Channel=2 in the pipeline we are getting as it is clock-rate on Hardware.
I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.
Did you like my answer?
Hello,
Thank you for your detailed explanation of the issue.
Summary of the Issue:
You are using GStreamer on Colibri iMX6ULL and iMX7D modules for audio playback.
When setting channels=1 (mono) in your pipeline, the measured word clock (WCLK) is about 10% lower than expected (e.g., for 8kHz, you measure ~7.1kHz).
With channels=2 (stereo), the clocks match the expected hardware rates.
Insights
What you observe is likely related to how the I2S controller generates clocks for mono (1-channel) vs. stereo (2-channel) audio formats. Many SoCs, including those on i.MX families, are primarily designed for stereo I2S, and running them in mono does not always change the word clock behavior as one might expect.
Typical I2S behavior:
WCLK (Word Clock): Typically matches the sample rate for both mono and stereo.
MCLK (Master Clock): May be fixed or related to sample rate (depending on codec/SOC).
Potential Cause:
On some hardware, when you set channels=1, audio data might still be output as if for 2 channels (mirrored mono or a zeroed unused channel). However, if the audio driver or hardware incorrectly sets the divider or frame size, you might see the word clock (LRCK/WCLK) frequency become lower, correlating with only one channel’s worth of data being clocked per frame—leading to a roughly 50% reduction if the interface does not handle mono natively. But your numbers suggest about a 10% drop, not 50%, which could indicate a mismatch between GStreamer/audio software configuration, ALSA driver, or even the hardware interface’s settings.
Suggestions
1. Verify ALSA and Device Tree Configuration
Check the Device Tree audio node for your Colibri iMX6ULL/iMX7D for fsl,sai or fsl,ssi properties. Make sure the dai-format and channel settings align with your hardware needs.
Sometimes, ALSA/SoC drivers require explicit settings or quirks to handle mono data correctly.
2. Experiment with Different mono-mode Handling
Some codecs or SoC drivers have options for “Mono Left”, “Mono Right”, or “Duplicated”. Experiment with these in your ALSA configuration or by passing extra parameters in GStreamer via alsasink.
3. Test with arecord/aplay or direct ALSA interface
Try playing a mono file directly with ALSA tools, e.g.,
The observed discrepancy in the word clock during mono playback is likely due to hardware or driver handling of mono mode; many embedded SoCs do not natively support genuine mono I2S transmission, and the resulting clock ratios can be off unless specifically handled in the driver or configuration.
If you can, provide details on which audio codec (if any) and audio bus type (I2S/SAI/SSI) you are using—this could help narrow down the configuration needed.
Please let me know if you would like more details on configuring the device tree for audio or further troubleshooting steps!
Hii sahil, Are you getting audio discontinuity in both the cases? yes. But I need to know is that why with channels=1 the wclk is decreased by 10% and why with channels=2 getting good wclk. why like this ?
what about this. Can I get any solution from you ?
Hi @Eswar,
I dont know the exact reason for this behaviour but looking into the driver source code may be get you to the reason. Please check the driver source code.
