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

[Hans de Goede <hdegoede@redhat.com>]

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 ?

Regards,

Hans