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

From: Tanu Kaskinen <tanuk@iki.fi>
To: Takashi Iwai <tiwai@suse.de>,
	Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: Hans de Goede <hdegoede@redhat.com>,
	alsa-devel@alsa-project.org,
	pulseaudio-discuss@lists.freedesktop.org
Subject: Re: [alsa-devel] pulseaudio fails to start with kernel 4.11, caused by new snd_hdmi_lpe_audio module)
Date: Fri, 24 Mar 2017 20:18:59 +0200	[thread overview]
Message-ID: <1490379539.24554.2.camel@iki.fi> (raw)
In-Reply-To: <s5hvar0fjzf.wl-tiwai@suse.de>

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?

-- 
Tanu

https://www.patreon.com/tanuk
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss