Output issues while using the HDMI (imxhdmisoc). AV Reciever behaves like the PCM frames are out of sync.

[GoogleCodeExporter]

What steps will reproduce the problem?
1.Starting:   squeezelite-armv7l-hdmi -s 127.0.0.1 -o default:CARD=imxhdmisoc 
-a 180:4:16:1 -b 4096:4096 -d all=sdebug -f /var/log/squeezelite_hdmi.log -m 
$main_mac_2 -n $name_2 -z
2.Play the Pandora steam using the Logitech Media Server(7.7.3). The sound 
becomes distorted after some period of time which is vary from 1 to 3 hours.

What is the expected output? What do you see instead?
The expected output is the normal audio playback.I have distorted sound out of 
the speakers. The receiver's stereo channel indicators are blinking rapidly.
At the same time the output to the SPDIF or to Analog is OK. The Squeezebox 
Media Server's control interface shows the normal playback.

To recover from the fault:  "Power Off" & "Power ON" the player  form 
Squeezebox Media Server web interface.

What version of the product are you using? On what operating system?

Squeezelite v1.5.  Debian 7.3 armv7l. HW: Utilite value 
(http://utilite-computer.com/web/utilite-value-specifications )

Please provide any additional information below.

Attaching the sdebug log. The system was running fine for almost 3 hours -  
Around 12:00:15 the problem started. Around 12:04:50 the sound is recovered.
Attaching 2 strace files. with/without the problem.

Specifying the -c mpg  is not producing any sound from Pandora
Starting with all default settings - same issue
Starting with S32_LE - same issue
Starting with mmap 0  - same issue + some other errors occasionally

Up to date was not able to reproduce the problem using "cat /dev/urandom | 
aplay -D hw:2,0 -f S32_LE -c 2 -r 44100 " 

-----------
root@squeeze-utilite:~# /usr/local/bin/squeezelite-armv7l-hdmi -l
Output devices:
  null                           - Discard all samples (playback) or generate zero samples (capture)
  default:CARD=wm8731audio       - wm8731-audio,  - Default Audio Device
  sysdefault:CARD=wm8731audio    - wm8731-audio,  - Default Audio Device
  default:CARD=imxspdif          - imx-spdif,  - Default Audio Device
  sysdefault:CARD=imxspdif       - imx-spdif,  - Default Audio Device
  default:CARD=imxhdmisoc        - imx-hdmi-soc,  - Default Audio Device
  sysdefault:CARD=imxhdmisoc     - imx-hdmi-soc,  - Default Audio Device
----------

Original issue reported on code.google.com by ginzburg...@gmail.com on 31 Jan 2014 at 1:33

Attachments:

• squeeselite_sdebug.log
• strace_normal.log
• strace_problem.log

[GoogleCodeExporter]

Assuming its the same freescale driver as used in the wandboard kernel, then I 
think turning off mmap resolves.  We have several users who have reported this 
(and that the corruption starts after a specific number of bytes transferred - 
so that it depends on the sample rate how long this is)

Try your aplay test with mmap enabled to make this a valid comparison.

Original comment by trio...@btinternet.com on 31 Jan 2014 at 10:07

[GoogleCodeExporter]

I was able to reproduce the problem using  -   "cat /dev/urandom | aplay -D 
hw:2,0 -f S16_LE -c 2 -r 44100 --mmap"

obviously, the simplest solution will be to run squeezelite with mmap disabled. 

Trying to run the squeezelite mmap disabled - brakes the ALSA after several 
minutes/ seconds. 

starting with  /usr/local/bin/squeezelite-armv7l-hdmi -s 127.0.0.1 -o 
default:CARD=imxhdmisoc -a ::16:0 -d all=sdebug -f 
/var/log/squeezelite_hdmi.log -m $main_mac_2 -n $name_2 -z

starting with   -a :::0 is the same.

Is is also able to recover after some time -  just to die again seconds after 

-----------------------------------------------------------------------
[10:08:06.200804] _output_frames:111 avail: 768 frames: 768 silence: 1
[10:08:06.200990] _output_frames:261 wrote 768 frames
[10:08:06.201042] ALSA snd_pcm_hw_delay:514 SNDRV_PCM_IOCTL_DELAY failed (-32)
[10:08:06.201079] output_thread:488 XRUN
[10:08:06.201155] _output_frames:111 avail: 768 frames: 768 silence: 1
[10:08:06.201338] _output_frames:261 wrote 768 frames
[10:08:06.201388] ALSA snd_pcm_hw_delay:514 SNDRV_PCM_IOCTL_DELAY failed (-32)
[10:08:06.201424] output_thread:488 XRUN
[10:08:06.201578] _output_frames:111 avail: 768 frames: 768 silence: 1
[10:08:06.201760] _output_frames:261 wrote 768 frames
[10:08:06.201810] ALSA snd_pcm_hw_delay:514 SNDRV_PCM_IOCTL_DELAY failed (-32)
[10:08:06.201847] output_thread:488 XRUN
[10:08:06.201924] _output_frames:111 avail: 768 frames: 768 silence: 1
[10:08:06.202099] _output_frames:261 wrote 768 frames
[10:08:06.202148] ALSA snd_pcm_hw_delay:514 SNDRV_PCM_IOCTL_DELAY failed (-32)
[10:08:06.202184] output_thread:488 XRUN
[10:08:06.202275] _output_frames:111 avail: 768 frames: 768 silence: 1
[10:08:06.202449] _output_frames:261 wrote 768 frames
[10:08:06.202499] ALSA snd_pcm_hw_delay:514 SNDRV_PCM_IOCTL_DELAY failed (-32)
[10:08:06.202535] output_thread:488 XRUN
[10:08:06.202623] _output_frames:111 avail: 768 frames: 768 silence: 1
[10:08:06.202798] _output_frames:261 wrote 768 frames
-----------------------------------------------------------------------------

Any advice?

Original comment by ginzburg...@gmail.com on 2 Feb 2014 at 10:37

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

error -32 is caused on XRUN so this suggests the output device is underrunning 
- but the messages suggest it is recovering ok.  Other than these errors what 
is the symptom?

Original comment by trio...@btinternet.com on 10 Feb 2014 at 9:15

[GoogleCodeExporter]

no audio.
there are playback gaps. it is going than stops(showing the ALSA log entries)
then recovers for several seconds ( log is normal ) and stops again ( with the 
same errors in the log) 

Original comment by ginzburg...@gmail.com on 10 Feb 2014 at 9:19

[GoogleCodeExporter]

Running pulseaudio is not crashing the ALSA while running mmap 0.

So the workaround for this issue will be running squeezelite with mmap 0
and  using the pulseaudio

I think you can close this for now

Original comment by ginzburg...@gmail.com on 20 Feb 2014 at 9:40

[GoogleCodeExporter]

closing as workaround found

Original comment by trio...@btinternet.com on 21 Feb 2014 at 10:25

• Changed state: WontFix