On Thu, 30 Mar 2017 18:06:47 +0200, Tanu Kaskinen wrote:
On Wed, 2017-03-29 at 16:51 +0200, Takashi Iwai wrote:
On Wed, 29 Mar 2017 16:40:28 +0200, Tanu Kaskinen wrote:
On Wed, 2017-03-29 at 15:26 +0200, Takashi Iwai wrote:
On Wed, 29 Mar 2017 15:14:19 +0200, Tanu Kaskinen wrote:
On Wed, 2017-03-29 at 15:06 +0200, Takashi Iwai wrote:
On Wed, 29 Mar 2017 14:59:45 +0200, Tanu Kaskinen wrote: > > On Wed, 2017-03-29 at 07:21 +0200, Takashi Iwai wrote: > > 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?
If the alsa-lib configuration just maps hdmi:1,0 to hw:1,0, then I would expect this problem to persist. If hw:1,0 can be opened, pulseaudio will think that there's an analog stereo output. If hdmi:1,0 works too, then pulseaudio will think that there are two separate outputs, and if the hdmi jack state says that hdmi is not available, pulseaudio will use what it thinks is an analog output.
Aha, that explains.
If it's not possible to change the device numbering in the driver, this will have to be worked around in pulseaudio somehow (pulseaudio shouldn't try to use hw:1,0 on this hardware).
Well, it's not impossible to change in the driver side, but I hesitate to do so, since it's not right, IMO.
In general, the PCM device#0 isn't always for an analog output, although it's de facto standard, as most boards have both analog and HDMI/DP. For HD-audio, we even kept the constant PCM dev# even if no analog output is present; but it's just to make the configuration easier, and it doesn't mean that PCM dev#0 is for the analog I/O.
I agree, it's not good to assume that hw:x,0 is always analog stereo output. Pulseaudio should fall back to hw: only if nothing else works.
The jack name problem is easily solved in pulseaudio, but there's one more problem related to the device numbers: pulseaudio needs to know which ELD element corresponds to which PCM device. Currently the mapping is hardcoded: hdmi:x,0 is expected to always correspond to the ELD element of device 3. Is there any way pulseaudio could query the mapping instead of hardcoding it?
Oh that's ugly. This mess comes from the HD-audio configuration, my bad.
The ELD index number is aligned with the PCM device number (in a way of hw:x,y), thus it's 3 for HD-audio. It's used for HDMI/DP jack, too.
I guess you can get this from snd_pcm_info() => snd_pcm_info_get_device() call for the opened stream? The usual plugins should return the slsave pcm info, so even for hdmi:x,y, it should reach to the underlying hardware PCM.
That sounds workable. Unless someone else wants to help with this, I'll work on the PulseAudio changes.
Please go ahead. I believe fixing this in PA is the best option.
thanks,
Takashi
I created a bug report here: https://bugs.freedesktop.org/show_bug.cgi?id=100488
-- Tanu