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

Takashi Iwai tiwai at suse.de
Thu Mar 23 08:57:56 UTC 2017

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?

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.


More information about the pulseaudio-discuss mailing list