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
