[alsa-devel] [pulseaudio-discuss] pulseaudio fails to start with kernel 4.11, caused by new snd_hdmi_lpe_audio module)

[Takashi Iwai]

On Wed, 29 Mar 2017 14:59:45 +0200,
Tanu Kaskinen wrote:
> 
> On Wed, 2017-03-29 at 07:21 +0200, Takashi Iwai wrote:
> > On Tue, 28 Mar 2017 22:10:28 +0200,
> > Tanu Kaskinen wrote:
> > > 
> > > On Fri, 2017-03-24 at 23:01 +0100, Hans de Goede wrote:
> > > > Hi,
> > > > 
> > > > On 03/24/2017 07:18 PM, Tanu Kaskinen wrote:
> > > > > On Thu, 2017-03-23 at 09:57 +0100, Takashi Iwai wrote:
> > > > > > On Thu, 23 Mar 2017 04:16:52 +0100,
> > > > > > Pierre-Louis Bossart wrote:
> > > > > > > 
> > > > > > > On 3/21/17 2:56 AM, Hans de Goede wrote:
> > > > > > > > I: [pulseaudio] alsa-sink.c: Using 1.0 fragments of size 352832 bytes
> > > > > > > > (2000.18ms), buffer size is 352832 bytes (2000.18ms)
> > > > > > > > I: [pulseaudio] alsa-sink.c: Time scheduling watermark is 20.00ms
> > > > > > > > I: [pulseaudio] alsa-sink.c: Driver does not support hardware volume
> > > > > > > > control, falling back to software volume control.
> > > > > > > > I: [pulseaudio] alsa-sink.c: Driver does not support hardware mute
> > > > > > > > control, falling back to software mute control.
> > > > > > > > I: [alsa-sink-HdmiLpeAudio] core-util.c: Successfully enabled SCHED_RR
> > > > > > > > scheduling for thread, with priority 5.
> > > > > > > > I: [alsa-sink-HdmiLpeAudio] alsa-sink.c: Starting playback.
> > > > > > > > I: [alsa-sink-HdmiLpeAudio] (alsa-lib)pcm_hw.c: SNDRV_PCM_IOCTL_HWSYNC
> > > > > > > > failed (-32)
> > > > > > > 
> > > > > > > Humm, single period and hw_sync failed, this could be testing the
> > > > > > > robustness of the single-period code and its mapping on multiple DMA
> > > > > > > descriptors? I haven't looked at the alsa module in eons but can't the
> > > > > > > number of periods be forced to two with module parameters while
> > > > > > > keeping the timer-based schedulng?
> > > > > 
> > > > > I think the code doesn't currently support this.
> > > > > 
> > > > > > It's -EPIPE and this is supposed to be the intentional error code from
> > > > > > HDMI LPE audio driver.  The streaming doesn't work when the gfx is
> > > > > > disconnected or the monitor audio is off.  It accepts the open, but it
> > > > > > returns -EPIPE for further accesses.
> > > > > > 
> > > > > > Maybe -EPIPE is no sensible choice, but the problem is that the driver
> > > > > > can't use the PCM DISCONNECT state because PA interprets it being the
> > > > > > complete disconnection of the card object instead of a temporary
> > > > > > disablement of PCM.
> > > > > 
> > > > > So is this a PulseAudio bug?
> > > > > 
> > > > > I: [alsa-sink-HdmiLpeAudio] alsa-sink.c: Starting playback.
> > > > > I: [alsa-sink-HdmiLpeAudio] (alsa-lib)pcm_hw.c: SNDRV_PCM_IOCTL_HWSYNC failed (-32)
> > > > > 
> > > > > The "Starting playback" message is printed just before the
> > > > > snd_pcm_start() call. PulseAudio doesn't check the return value of
> > > > > snd_pcm_start(), but maybe it should? Does the HWSYNC happen in
> > > > > snd_pcm_start()?
> > > > > 
> > > > > Can this EPIPE thing happen also during playback, not just when
> > > > > starting?
> > > > 
> > > > So is this the likely cause of the RT code killing pa, or do you
> > > > still need me to gather perf output ?
> > > 
> > > The perf output would be interesting.
> > > 
> > > It's still unclear to me if the hwsync thing is a bug in alsa, or
> > > something that pulseaudio should deal with. If there's no further input
> > > from the alsa developers, would you be able to test a pulseaudio patch
> > > if I write one? First I'd like to check whether the hwsync error
> > > happens inside snd_pcm_start(), and if so, does the error get reported
> > > in the snd_pcm_start() return value. If snd_pcm_start() returns an
> > > error, pulseaudio should probably react to it, although I'm not sure
> > > how. It would be easy to just remove the sink if there's an error, but
> > > I understood Takashi's comment so that it might be an intermittent
> > > error that depends on the graphics state, and if that's the case,
> > > pulseaudio would have to retry when the graphics state changes, but I
> > > don't know what kind of event could be used to get a notification about
> > > the state change.
> > 
> > Does PA really need to start streaming at its invocation time?
> > The crash happens when PA gets started via desktop autostart, and at
> > this moment, the HDMI graphics state is possible disconnected before
> > xrandr setup.  The HDMI connection state should have been informed /
> > notified to PA via the jack interface, so it should be possible to
> > judge beforehand.
> > 
> > Or it might be something wrong in the driver side regarding the jack
> > state processing?
> 
> I had a closer look at the PA log that was posted earlier. It looks
> like the device numbering is non-standard. Trying to open any of the
> hdmi:1,x devices fails. hw:1 can be opened, and pulseaudio assumes that
> it's an analog stereo device. Jack detection isn't going to work in
> this situation, because pulseaudio doesn't know that it should be
> looking at the hdmi jacks.
> 
> Can the driver be fixed to use the standard HDMI device numbers?

Hmm, it might be the missing hdmi PCM definition?

The latest alsa-lib git already contains the card config for HDMI LPE
audio, and this might help.  (Though, I thought I still saw the same
PA problem even with the card config.  Unfortunately I can't access
the box with the DP audio right now, so others may help more quickly
than me...)

Can anyone confirm that you have the latest alsa-lib git installed and
whether the PA issue is fixed or not?


thanks,

Takashi