I2S (RPI as a slave) audio stuttering on RPI 3 since 4.4.6

[gtrainavicius]

Hello,

We are developing an audio card for RPI with one stereo input and one stereo output, and we've hit a stuttering issue with playing audio while at the same time recording. If audio is just being played without recording at the same time it is played alright.

On our board we use the following configuration: the ADC is the I2S master, DAC is a slave and RPI is a slave.

Furthermore, the same card with the same module code works just fine on RPI 2, even on the 4.4.x kernel, and RPI 3 itself works fine on 4.1.x kernel, with the same code apart from .dtb instead of .dtbo for the overlay and one argument less for GPIOD family of functions.

Please see the screenshot below, it was produced by loopbacking the input and output of the card with a cable, generating a 440Hz 30 second sine wave using audacity, then recording it using different sampling rates. As you can see, the 96000 sampling rate doesn't even record anything.

Thank you,
Giedrius.

[clivem]

I'm clutching at straws, but ISTR that the fix for I2S channel swap went in around 4.4.6 or 4.4.7.
3de2328

[pelwell]

Was it the switch from 4.1 to 4.4 that caused the problem, or a change within 4.4? You can use rpi-update to choose a specific firmware release using the commit IDs listed here.

[gtrainavicius]

I've narrowed it down to be between 4.1.21 (still working) and 4.4.6 (broken) releases.

Keep in mind that RPI 2 using 4.4.6 and newer works well, so it must be caused by some difference between the RPI 2 and RPI 3.

Let me know what you'd like me to try out, I've already tried disabling bluetooth as suggested in other I2S issue, and disabling wireless lan, but the issue still persists.

[pelwell]

Have you tried more recent commits? There was a change just before the jump to 4.4.10 that squashed a lot of unwanted UART interrupts.

[gtrainavicius]

The same issue reproduces with all the 4.4.x releases I've tried, including the latest 4.4.12.

[gtrainavicius]

I'm clutching at straws, but ISTR that the fix for I2S channel swap went in around 4.4.6 or 4.4.7.

I have tried reverting the mentioned commit and rebuilding snd-soc-bcm2835-i2s module, but the issue still reproduces.

[clivem]

I have tried reverting the mentioned commit...

Yes, that really was clutching at straws, rather than any real expectation that reverting that commit would solve your issue. Just out of interest, do you have MMAP enabled, either by hacking support back into the bcm2835-i2s driver or using 'dtoverlay=i2s-mmap'?

[gtrainavicius]

The issue still occurs with i2s-mmap enabled, but the behavior is slightly different - when trying to record at 96kHz, the recording is stuck, instead of recording silence. The other sampling rates behave the same as shown in the previous screenshot.

[clivem]

@msperl Martin and @HiassofT Matthias, do you have any thoughts?

[HiassofT]

Just tested simultaneous playback and recording with the Cirrus Logic Audio Card, using kernel 4.4.12 with my cirrus driver and everything worked as expected.

This was also on RPi3, 96kHz stereo S16_LE. But I used arecord and aplay on the command line, not audacity.

@gtrainavicius can you check if this also fails with arecord/aplay?

One difference between my cirrus tree and the RPi tree is that it includes fixes for the broken period/frame calculation and allow periods up to 64k-4 bytes (instead of 32k). But the period size code is the same in 4.1 and 4.4 so I don't think that could explain your issues.

Here's my tree, the period fixes are the first 4 commits on top of the rpi tree (the ones with bcm2835-i2s/dma in the commit message)
https://github.com/HiassofT/rpi-linux/tree/cirrus-4.4.y

[gtrainavicius]

I can't use 16 bit sample formats - the card's ADC and DAC run on 24 bits.

Using arecord & aplay on 96kHz seems to be recording, but trying to record on 192kHz still results in silence gaps every ~128 milliseconds.

Furthermore, I've seen occasionally getting short bursts of random or old data in the similar period of time, hinting that this might be some wrong or mismatched buffer size calculations somewhere.

Still I can't figure out why the RPI 2 works just fine with 4.4.12 kernel while RPI 3 has these issues on the same kernel version (and no problems on 4.1.x kernels)

One thing that's different within the same kernel release is the device tree between RPI 2 and RPI 3. Are there more such areas that could make a difference in the same release?

Would it be possible for me to do a 'binary search' in between the commits of 4.4.6 and 4.1.21 releases to find the exact moment the issue I'm seeing appeared?

[HiassofT]

Have you checked with aplay/arecord on the command line? Especially look out for overrun/underrun errors, you might be running into an IO bandwidth issue with the SD card (or did you record to an USB hdd?).

With the original 8GB (black Samsung) NOOBS card I had dropouts/underruns when playing back 192kHz 24/32 bit WAVs on RPi2 and RPi3 when they weren't cached in RAM, using a 32GB EVO / EVO+ ifixed that. That was only playback, haven't checked simultaneous playback/recording yet.

[msperl]

I am currently on a business travel, so got minimal access to rpi hw, but some things come to my mind:
Does it happen:

• with the upstream dma patch as well?
• does it show up writing to a RAM disk? (My estimate indicates that 60 seconds should consume about 64mb, so I guess it should be possible to reproduce it in such a window)
• does it show when using the same mmc driver (mmc or Sdhci - can't remember which is used where) on the rpi3 as on the rpi2 - there is a difference here, so that the rpi3 supports wifi!
• does it happen when SRAM calibration is disabled in the firmware - I heard there was a means to do this.

The reason why I ask the last point is because the one thing that may be different between a rpi2 and a rpi3 - assuming you run identical kernels - could be different behavior in the firmware. Maybe the firmware is clocking down the arm/Vpu because of heat or similar when those glitches happen, which would mean changing the Vpu frequency, which would mean changing the axi clock, which would mean shortly stopping Vpu/axi clock, but then it should impact playback as well and not only recording...
So maybe:

• run the test inside a fridge/freezer to see if this is impacting us.

Also: are there any intervals at which these gaps/glitches happen.

[HiassofT]

A simple test would be to run "arecord | aplay" on the command line, that'll bypass mass-storage IO.

Or try "dtoverlay=sdhost" on the RPi3, then the RPi3 uses the same SD/MMC driver as the RPi2.

[clivem]

@gtrainavicius Just to follow-up on one of Martins points about trying the new dma code....

Suggest you use the https://github.com/msperl/linux-rpi/tree/rpi-next-merged-patches-not-accepted-upstream if you are going to try it.

@msperl Have you re-based against latest rpi-4.4.y? Is he going to run into issues with conflicts because of those last clock patches from Eric if he tries to sync it to latest rpi-4.4.y?

I'm still smiling at the concept of testing with refrigeration..... LOL.