I2S Sync error with 4.9.20 on Raspbian

[moodeaudio]

Hi,

With 4.9.20 on Raspbian (2016-03-18 release) I see "I2S SYNC error!" in DMESG, no audio and unresponsive system when feeding 192k sample rate via MPD/SoX to I2S audio devices.

Tested with Pi2 and 3, Mamboberry LS, IQaudIO DAC PRO, Hifiberry DAC Pro. Rates less than 192k work ok and all rates work ok with 4.4.50.

[ 19.900705] bcm2835-i2s 3f203000.i2s: I2S SYNC error!
[ 30.566913] bcm2835-dma 3f007000.dma: DMA transfer could not be terminated

-Tim

[HiassofT]

The I2S sync error is harmless, it has been there forever (when bcm2835-i2s is configured as clock slave).

"DMA transfer could not be terminated" is the real issue, that usually occurs when a soundcard (acting as I2S clock master) fails to set up the clocks.

I did a quick test here with the Cirrus Logic audio card (which is a I2S clock master as well) and couldn't reproduce the issue - 192kHz 32bit audio played fine with kenel 4.9.20 on RPi3..

[pelwell]

@iqaudio @hifiberry @shawaj Have you seen any issues with high sample rates on 4.9 kernels? The rpi-update firmware currently includes 4.9.20.

[moodeaudio]

The Mambo and IQaudIO boards act as slave and still the issue with 192k and hang.

According to a colleague of mine no issues with 4.9.20 and rates on Archlinux. I noticed that most recent release of Raspbian still on 4.4 so perhaps this is unique to Raspbian or the particular 2016-03-18 release that I'm using. Btw I used rpi-update to bump to 4.9.20.

[pelwell]

For this particular issue the distribution should be irrelevant with the same kernel and kernel config settings.

[moodeaudio]

Thats what I thought.

[shawaj]

Not had any reports of this here. What issue are you seeing?

[pelwell]

I see "I2S SYNC error!" in DMESG, no audio and unresponsive system when feeding 192k sample rate via MPD/SoX to I2S audio devices.

[HiassofT]

Did another test, with IQaudio DAC+ (I2S slave) on RPi2, Raspbian lite with all updates and all looks well.

I tested with aplay, output looks like this:

pi@rpi2:~/audiotest $ aplay -v 192-32.wav
Playing WAVE '192-32.wav' : Signed 32 bit Little Endian, Rate 192000 Hz, Stereo
Plug PCM: Hardware PCM card 0 'IQaudIODAC' device 0 subdevice 0
Its setup is:
  stream       : PLAYBACK
  access       : RW_INTERLEAVED
  format       : S32_LE
  subformat    : STD
  channels     : 2
  rate         : 192000
  exact rate   : 192000 (192000/1)
  msbits       : 32
  buffer_size  : 65536
  period_size  : 16384
  period_time  : 85333
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 16384
  period_event : 0
  start_threshold  : 65536
  stop_threshold   : 65536
  silence_threshold: 0
  silence_size : 0
  boundary     : 1073741824
  appl_ptr     : 0
  hw_ptr       : 0

@moodeaudio could you also check with aplay?

[moodeaudio]

@HiassofT, that result would suggest its not a 4.9 issue. You used J-Lite 2017-03-02 image then rpi-update, correct?

[HiassofT]

@moodeaudio I've been testing with an older Raspbian lite Jessie release (probably end of 2016) with all package updates installed. Did an apt-get update/upgrade and rpi-update before the tests. I've tested with aplay and play, both worked fine.

I also did another test with the current LibreELEC 8 tree (also on kernel 4.9.20) and the Cirrus Logic card on RPi3, 192kHz/32bit worked fine as well with kodi.

At this point I wouldn't rule anything out, just trying to reproduce your issue.

[moodeaudio]

@HiassofT, I'm able to confirm a success case using 2017-03-02 J-Lite + apt update/upgrade + rpi-update to 4.9.20 and the generic audio test cmd below with IQ DAC+ and Mambo LS. Audio is fine.

speaker-test -c 1 -r 192000 -F S32_LE -f 440 -t sine -l 1

But I have a side issue after I create a full Moode/MPD build on top of 2017-03-02 J-Lite + 4.9.20. The 96k rate sounds fine but 192 rate sounds at least 1/2 octave lower using the generic audio test cmds below. Also same result If I play a native 24/192 song file or resample everything to 24/192 using MPD/SoX. NOTE: no issue using 4.4.50.

speaker-test -c 1 -r 96000 -F S32_LE -f 440 -t sine -l 1 (sounds fine)
speaker-test -c 1 -r 192000 -F S32_LE -f 440 -t sine -l 1 (sounds 1/2 octave lower)

So I think "I2S SYNC error..." issue can be closed. Further investigation required to analyze the side issue since it seems tied to the particular combination of Moode full build / 4.9.20 / Raspbian latest release.

[moodeaudio]

@HiassofT, Below is a repro of the 192k / I2S SYNC / DMA issue using plain Raspbian and speaker-test util.

The issue occurs after running the tvservice app. This app is run during Moode startup which explains why 192k was failing on full Moode build.

--Start with latest 2017-03-02 Raspbian release

sudo nano /boot/config.txt
dtparam=i2c_arm=on
dtparam=i2s=on
dtparam=audio=off
dtoverlay=iqaudio-dacplus

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install rpi-update
sudo reboot
sudo rpi-update
sudo reboot

--This is the success case

speaker-test -c 2 -r 192000 -F S32_LE -f 440 -t sine -l 1

speaker-test 1.0.28

Playback device is default
Stream parameters are 192000Hz, S32_LE, 2 channels
Sine wave rate is 440.0000Hz
Rate set to 192000Hz (requested 192000Hz)
Buffer size range from 64 to 65536
Period size range from 32 to 32768
Using max buffer size 65536
Periods = 4
was set period_size = 16384
was set buffer_size = 65536
0 - Front Left
1 - Front Right
Time per period = 5.668034

--This is the failure case

tvservice -o
Powering off HDMI

speaker-test -c 2 -r 192000 -F S32_LE -f 440 -t sine -l 1

speaker-test 1.0.28

Playback device is default
Stream parameters are 192000Hz, S32_LE, 2 channels
Sine wave rate is 440.0000Hz
Rate set to 192000Hz (requested 192000Hz)
Buffer size range from 64 to 65536
Period size range from 32 to 32768
Using max buffer size 65536
Periods = 4
was set period_size = 16384
was set buffer_size = 65536
0 - Front Left
Write error: -5,Input/output error
xrun_recovery failed: -5,Input/output error
Transfer failed: Input/output error

DMESG
[ 88.652363] bcm2835-i2s 3f203000.i2s: I2S SYNC error!
[ 109.287268] bcm2835-dma 3f007000.dma: DMA transfer could not be terminated

[HiassofT]

@moodeaudio I followed the steps you outlined but still can't reproduce the issue.

I did a fresh install of Raspbian Lite, had a (DVI) monitor connected, enabled ssh and ran the commands via ssh on a RPi2 with IQaudio dac plus (on a fresh boot, removed power before):

pi@raspberrypi:~ $ uname -a
Linux raspberrypi 4.9.21-v7+ #986 SMP Tue Apr 11 17:06:55 BST 2017 armv7l GNU/Linux
pi@raspberrypi:~ $ tvservice -o
Powering off HDMI
pi@raspberrypi:~ $ speaker-test -c 2 -r 192000 -F S32_LE -f 440 -t sine -l 1

speaker-test 1.0.28

Playback device is default
Stream parameters are 192000Hz, S32_LE, 2 channels
Sine wave rate is 440.0000Hz
Rate set to 192000Hz (requested 192000Hz)
Buffer size range from 64 to 65536
Period size range from 32 to 32768
Using max buffer size 65536
Periods = 4
was set period_size = 16384
was set buffer_size = 65536
 0 - Front Left
 1 - Front Right
Time per period = 5.682326
pi@raspberrypi:~ $

config.txt:

pi@raspberrypi:~ $ cat /boot/config.txt
# For more options and information see
# http://rpf.io/configtxtreadme
# Some settings may impact device functionality. See link above for details

# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1

# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
#disable_overscan=1

# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16

# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720

# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1

# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1

# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2

# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4

# uncomment for composite PAL
#sdtv_mode=2

#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800

# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

# Uncomment this to enable the lirc-rpi module
#dtoverlay=lirc-rpi

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
#dtparam=audio=on

dtparam=i2c_arm=on
dtparam=i2s=on
dtparam=audio=off
dtoverlay=iqaudio-dacplus

Edit: added the FW version info:

pi@raspberrypi:~ $ vcgencmd version
Apr  4 2017 18:41:29
Copyright (c) 2012 Broadcom
version 3ca4cf4a663c5351eaec08b29d50d6e8324981b4 (clean) (release)

[moodeaudio]

@HiassofT, try headless without monitor connected.

[HiassofT]

@moodeaudio thanks, I've finally been able to reproduce the issue with the following setup:

• no monitor connected during powerup (RPi uses composite video out)
• dtoverlay=rpi-dac added to config.txt (no HW required), dtparam=audio=on commented out
• testing with speaker-test -Dhw:0 -c 2 -r 192000 -F S32_LE -f 440 -t sine
• running tvservice -o to disable video output

Another interesting test:

• powerup RPi without monitor
• run speaker test, verify with a scope that I2S bit-clock is running at 12.288MHz and frame-clock at 192kHz
• run tvservice -o and see I2S clocks go away (flat line)
• run tvservice -c "NTSC 4:3" and watch I2S clocks coming back to normal

@pelwell @popcornmix this looks like a clock or firmware issue, could you have a look at it?

[pelwell]

It sounds like a simple case of a clock being disabled when it shouldn't (or not being enabled when it should) - I hope it proves as simple to fix.

Thanks for doing the legwork on this, @HiassofT.

[popcornmix]

@pelwell 's fix is in latest rpi-update kernel. Can you test it fixes your problem?

[moodeaudio]

Yes of course, I will test and post back results asap.

[moodeaudio]

After retesting I can confirm that latest 4.9.24 via rpi-update fixes the issue.

Many thanks!

[mr-berndt]

I am also having this issue, but only when trying to use jackd together with a HiFiBerry Digi+ I/O or a HiFiBerry Digi+ pro. It doesn’t happen with regular HiFiBerry, or IQAudioDAC.
Using aplay works without issue.

I checked with two OS, Raspbian with kernel 4.14.71 and my own build root build with kernels 4.14.34 and 4.14.74.

Jack startup looks ok but jackd fails shortly after:
pi@raspberrypi:~ $ jackd -d alsa
jackdmp 1.9.12
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2016 Grame.
Copyright 2016-2018 Filipe Coelho.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
#JACK server starting in realtime mode with priority 10
self-connect-mode is "Don't restrict self connect requests"
creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|32bit
configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 24bit little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 24bit little-endian
ALSA: use 2 periods for playback

...

JackAudioDriver::ProcessAsync: read error, stopping...

When that comes, dmesg shows:
[ 23.966746] bcm2835-i2s 3f203000.i2s: I2S SYNC error!
[ 102.845095] bcm2835-dma 3f007000.dma: DMA transfer could not be terminated

The problem is confirmed with two different cards respectively and two different pis.

[t0k4rt]

+1
I've got the same issue on a raspberry pi 3 with hifiberry digi+
raspberrypi kernel: bcm2835-dma 3f007000.dma: DMA transfer could not be terminated

[jshep321]

Hi,
I'm running shairport-sync on an audioinjector (stereo) on a pi zero W. The dma termination issue drove me crazy.

Of course the solution (in my case) was stupid simple: Run alsamixer and unmute (press M) on the "Output Mixer HiFi" so it shows "oo". Then run sudo alsactl store to enable these settings post-reboot.

I have put an issue on the audioinjector forum as this should be included, at the very least, in the setup instructions.

My theory: dma termination won't work if there is no endpoint. And that endpoint, for some reason beyond my understanding, doesn't exist/enumerate/etc. until the target output is UN-muted.

Tl;dr: play around with alsamixer settings for your particular sound card and see if it fixes this.