I’ve been working on audio on a Genio 520 EVK with IoT Yocto v25.1 PR5. Attempting to use I2SIN1 and noticed some issues with data corruption. Data on I2S wires looked okay with pattern data and logic analyzer, but there were mismatches when recorded on the Genio.
As a simpler test I used “arecord -D i2s_in1 -f S16_LE -r 48000 -c 2 > test1.wav” to record, with I2SIN1_DI pulled constantly high. I would have expected it to record all 1s, but a 5 second recording had a few segments with many “00 00 FF FF 00 00 FF FF” rather than “FF FF FF FF FF FF FF FF”.
As part of further debug attempts it was somewhat randomly noticed that running the command “arecord -D hw:0,30 -f S16_LE -r 48000 -c 2 > /dev/null” seemed to somehow fix things, and even though this command instantly failed with “Unable to install hw params” error. After running that once, was able to record all 1s with I2SIN1_DI high, and looping audio through to the default earphone out jack worked okay without major distortion with “arecord -D i2s_in1 -f S16_LE -r 48000 -c 2 | aplay”.
This is good for making progress, but still not expected. Any idea why?
Hi @Chris_Dohnal
I2SIN1 is disabled by default and will only be enabled if the it6625 dtbo is selected during image flashing. Therefore, it is expeced to record an empty file if the it6625 dtbo is not selected.
And the hw:0,30 device does not exist on Genio 520-EVK, so it cannot be used.
You can use the arecord command to check all available recording devices.
arecord -l
Are any additional device tree additions needed to enable and use I2SIN1 in master mode?
I found the small sound related fragment in camera-it6625-csi1-std.dts, but I also saw in the PR5 change log “I2S ports can now be configured as slave to suport master-only devices such as IT6625.” We like having the slave option, but for this specific test trying to see if can use it in master mode.
I had noticed pcm.i2s_in1 in asound.conf, and the two commits “GENIO: arm64: dts: mt8391-genio-720-evk: Add I2SIN1 configuration” and “GENIO: ASoC: mediatek: mt8189: Add I2S set format support”, and was wondering if might work. Things looked okay at first as MCK, BCK, LRCK all came on when started to arecord it, but after that noticed major distortion and the data not looking quite right after saved it to a file.
We’re looking at using I2S with custom external device (a somewhat flexible MCU, not an IT6625), and still haven’t finalized all of the details yet.
Hi @Chris_Dohnal
You can enable I2SIN1 in the DTS file: G520 DTS
dai-link-3 {
link-name = "I2SIN1_BE";
status = "okay";
};
And I2SIN1 is set to master mode by default.
Could you provide us how you measure the clock and record the file, including the commad you use?
I mostly run two commands, which are variants of the same thing:
Loopback : arecord -D i2s_in1 -f S16_LE -r 48000 -c 2 | aplay
Record : arecord -D i2s_in1 -f S16_LE -r 48000 -c 2 > test1.wav
I just tested overlay that added to device tree:
dai-link-3 {
link-name = "I2SIN1_BE";
status = "okay";
};
verified with decompile /sys/firmware/fdt from the running system (and saw it had been “disabled” before).
Still saw odd distortion, until ran that probably invalid command again once “arecord -D hw:0,30 -f S16_LE -r 48000 -c 2 > /dev/null” As part of earlier debug I had run many commands just to see if any of them might happen to work or do something. Noticed later that something might have fixed a test tone test, and then went back through many of them and discovered this one may have some sort of useful side effect in my case.
For clock measurement I have approximate from logic analyzer. Haven’t noticed any issues there. Saw MCK, BCK, LRCK come on when arecord running and off when stop it. Saw BCK and LRCK at expected frequencies for a few common audio bit rates had tested.
Planning to test I2SIN0 soon, and will see if notice anything different there.
I tried I2SIN0, but still see odd distortion. Using slightly modified loopback command:
arecord -D i2s_in0 -f S16_LE -r 48000 -c 2 | aplay
If I run “arecord -D hw:0,29 -f S16_LE -r 48000 -c 2 > /dev/null” once, then the distortion is no longer present when I try subsequent loopback tests.
Hi @Chris_Dohnal
I2SIN1 on the Genio 520-EVK is not connected to any signal source, so the recorded audio file is expected to be empty.
Or have you already connected I2SIN1 to another codec for testing?
And I don’t quite understand the purpose of these commands you executed:
arecord -D hw:0,29 -f S16_LE -r 48000 -c 2 > /dev/null
arecord -D hw:0,30 -f S16_LE -r 48000 -c 2 > /dev/null
Do you mean that after you run these two commands, I2SIN1 is able to successfully receive data on your side?
Yes, that is mostly it, and it is odd. I don’t even know exactly what those commands are doing, though I suspect they may cause something to happen in the kernel that has some sort of side effect. Call them an accidental discovery that might be useful.
For latest testing, I have an output path working, and moved to I2SIN0, so my Genio side loopback command is now:
arecord -D i2s_in0 -f S16_LE -r 48000 -c 2 | aplay -D i2s_out0
If I run that initially, I hear the major distortion. If I run the odd command once:
arecord -D hw:0,29 -f S16_LE -r 48000 -c 2 > /dev/null
And then go back to the loopback command, it works great and everything sounds okay.
If it doesn’t look like anything simple, there are a couple other things I can likely check in the next couple days. I remembered we have some other audio changes related to Bluetooth audio, that I wouldn’t expect to interfere with this, but I can try rebuild the customized demo image with all of those removed. We also should have someone else setting up to look at the same audio path soon, so can see if notice anything odd there, or if only something odd with my setup.
I tested with the IoT Yocto v25.1 prebuilt image, and no problems. Sorry, should have done that before. And yet still may have more questions in a few days depending on what might find. Still very odd the way seeing things not working with this, and how the odd invalid command has a side effect that clears things up.
I’ll go through and try to see what change we made to the demo image that may have caused this, or if not that try starting from a clean full rebuild. Already tried testing with many changes removed. Besides that we have some other changes that either seem very unlikely to interfere with audio, or the other audio changes we made related to higher level services and Bluetooth audio that I wouldn’t expect to interfere with I2S like this, but may still be the next best thing to try testing with removed completely. Though if it does happen to be something there, will need to debug that as do need these others things working too.
Hi @Chris_Dohnal
By default, whether it’s I2SIN0 or I2SIN1, using this command should only result in clock output, but you won’t hear any sound, because I2SIN is not connected to any signal output.
arecord -D i2s_in1 -f S16_LE -r 48000 -c 2 | aplay
And since you didn’t specify the output device, you need to check what your default output device is. You can use the wpctl command.
wpctl status
To test I2SIN, you can use the I2SIN0_LPBK kcontrol to loop back I2SOUT0 to I2SIN0 internally.
Then output the signal via I2SOUT0 and you can record it with I2SIN0.
amixer -c 0 cset name='I2SIN0_LPBK' 1
For I2S1, please use the I2SIN1_LPBK kcontrol.
Thanks, good to know about more options for debug. We also ran a few more tests and learned a lot.
I tested my own PR5 build of rity-demo-image with all changes backed out and still saw the problem. Also, saw the problem on a 2nd setup with something PR5 based and not built by me.
However, I just got my own build updated to the recently released IoT Yocto v25.1 (2025 Dec 30), and I’m not seeing any problems with that with my own build of rity-demo-image. So that’s very good, except if may want to track down a more specific cause. Considering the nature of the odd problem and what has been looked at so far, that may be difficult, so there’s a good chance we may watch this going forward, but have to evaluate and defer any further investigation into the future a ways.
I’ll look through recent commit logs a bit, but not sure likely to find anything obvious there. I’ll also soon add back all the changes we’ve made to image based on rity-demo-image and make sure it still works, but not anticipating any issues there.