Hi Wichmann,

Do you mean the issue is caused by the patches 1480992519-108079-1-git-send-email-libin.yang@intel.com?

I can't see which patches are included you mentioned in the link.

Do you know if the DP MST audio mode is used in your case?

Regards, Libin

-----Original Message----- From: alsa-devel-bounces@alsa-project.org [mailto:alsa-devel-bounces@alsa- project.org] On Behalf Of Pascal Wichmann Sent: Thursday, March 30, 2017 6:22 PM To: Libin Yang libin.yang@linux.intel.com; alsa-devel@alsa-project.org Subject: Re: [alsa-devel] Problems with the DP MST audio support patchset

...

I am not sure what these problems are caused by and do not know what kin d of debug information you may require to get more hints on how to solve them. Any hints are appreciated.

I have run alsa-info.sh to get more details: http://www.alsa- project.org/db/?f=124149d1cae74a6622176e13f9c5c63b5411af88

Hi Pascal,

-----Original Message----- From: Pascal Wichmann [mailto:pascal.wichmann@pa-w.de] Sent: Friday, March 31, 2017 12:36 AM To: Yang, Libin libin.yang@intel.com; Libin Yang libin.yang@linux.intel.com; alsa-devel@alsa-project.org Subject: Re: [alsa-devel] Problems with the DP MST audio support patchset

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Hi,

...

Do you mean the issue is caused by the patches 1480992519-108079-1-git-send-email-libin.yang@intel.com?

I don't know whether the issues are caused directly by the specific patches; without them, digital audio does not work at all in my setup. Using analog audio however does not have the problems mentioned in my first email.

...

I can't see which patches are included you mentioned in the link.

I am building my kernel from drm-tip. The relevant patches enabling DP M ST audio seem to be "ALSA: hda - add DP mst verb support" [0] as well as "ALSA: hda - add DP MST audio support" [1].

...

Do you know if the DP MST audio mode is used in your case?

I think it is used; at least dp/hdmi audio does not work at all without building against drm-tip. (the outputs are all stated as unplugged and unavailable in pavucontrol for example) Is there any way to know for sure?

Get it. Basically, 5.1 audio should work. What format are you using for testing the 5.1 audio?

Regards, Libin

Regards, Pascal

[0] https://cgit.freedesktop.org/drm-tip/commit/?id=13800f397ee3b4996f316b9c aa8482cb90edef0d [1] https://cgit.freedesktop.org/drm-tip/commit/?id=9152085defb6426ce8f9989c a27e4450daefbd89 -----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE/gJ8Tpn0OtJz8hxD6+YIa34W/zYFAljdM90ACgkQ6+YIa34W /zZk8A//YmadcSwYQTJIJKHJREjGSITGPx6wQYA8dix2EvP0frhnL5LEAfzCUD0b 05H9cc+kBG3z6dIs6yytX6TFtKlqnE/ka1D80+ZYiMf/RTYpowJWXogoPF8iVW68 MTaUtM5/CGhFF/e1V7AKDX36r5eVKYwKNUIb1vXE+nU6WbuzNrQn/vgwtIboC Xsj AQVC9RT7sRHnNVNq+WD4NYNSKfTJasnhbGo1+X3eTjY5vcWb/5H3ysaayW9W qnkI W3jYdoQmWCDZC14dKGnNZJ5J1WlF03qh95bQTJB7CDl66Nqqck621MbSzLp3+ 2xv 0eliZLcdumLhzu6wjTKcqXsyhejhRYYR25AfKGvB8zbujKnHZOSWO1T5QgJKOVHY oAQAgivpmNppGuNBmFKOWDnB5pec+kx3YDo9TnTUhPfXs04vGV0nnzugt9iu9 STq kzhu5fTmRfNK6uImcL4lo8JKmFu8Ws60kO0OcuUh8xd0dFy1vNF4qA0cZZywBG p+ YSsTzKhljHiq2aV1CpG2xMIom1YR38agTVWbL1aeGZf3FZUhD1+G9aLB1Lz6dmf g lLlne94HGnvgGoJkTx7BR6MRmUDDb4E8sdnx/yGtJ8ILKImAMJBURHfdcv3wp+G C oihf+BjIdV7BSDFMBxW/UeEM616rmNOGbG7zWxXoH6ZTWB50CwA= =8Sl2 -----END PGP SIGNATURE-----

Hi Takashi,

Do you have some suggestion for this issue.

Hi Pascal,

Please see my comments below.

-----Original Message----- From: Pascal Wichmann [mailto:pascal.wichmann@pa-w.de] Sent: Friday, March 31, 2017 2:12 PM To: Yang, Libin libin.yang@intel.com; Libin Yang libin.yang@linux.intel.com; alsa-devel@alsa-project.org Subject: Re: [alsa-devel] Problems with the DP MST audio support patchset

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Hi,

...

Get it. Basically, 5.1 audio should work. What format are you using for testing the 5.1 audio?

I do not use a specific format for testing; the issue occurs using speaker-test as well as using any application with audio output as for example vlc, rhythmbox or a browser like chromium or firefox.

As mentioned, when configuring the output as digital stereo or 7.1 surround, except for the second issue explained in my first mail (which actually is more annoying) the audio works.

Yes, that's strange. I asked about the format is try to make sure you are using the same format as 7.1. As you are using speaker-test, the format is not the problem.

We tried to reproduce this issue here and unfortunately failed. We can't make the HDMI work through our AV receiver.

I checked your alsa-info.sh output and didn't find the problem.

Regard, Libin

Regards, Pascal -----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE/gJ8Tpn0OtJz8hxD6+YIa34W/zYFAljd8yIACgkQ6+YIa34W /zY3Bw/+MW4ziQgRwY8/ElLytL9ewBQaft4DZLZoVaJomIwhgpr1y135rpJRnmM B XkQk9Qr7qMTmE8/wTssEwJwZ38HFcrn5sSGlhIPIcqy3J3D4EM3ANTo0xzl2yoYc zLxPuu+t+hPBeWOZgK34IjhQzuRZLXx5lsPFNpCAzJKbP8RTExw1Zu+OvbZQAieU YM7T6nf3s98BF2/1DLdXjl62PDxVQ08olPM/euEhi3DzsZs60hIkI6ebNsXy6xnN Os+bHh5Mgc5vdjjDEQ9+or8aPFd9FeOo1qSZemNPe3h8OLCtuUt53SkmJwqpW 3qH L8Wa/xjOxPFDVw9Ehyp+jD51s4lY+xk0h4+De+lL1pq0srNM1NdDEh0+x5kjCBf9 l2XaXN0sxmDmJkIRzdPYrQ1NB3ieNAhqHGcj+Zb4x/gzH8WJ8Z/+VQZVu4sntorj 4JcIzmw7U8LdU2t3ytqZ6JTlrr1t+V31gIDQuB1M5G336Qj7F5XVJxVc989uEOkP qWIMLXrWXUhKqMSBfpQkTAFKGbD4xR6A9Em/efRdXFkZH+AXiZxTSfZt1dSFqO Z6 OtVhL3Ew4RW7xSXTwILB1eh4uoFnztLm9VCB9JGoge2OQII8QcNMUbdoNtoNjL xh XkMkWCnd8iPYH0ix0dMKdaTI0c8JUCWZKjun2Tx9jePLoMuqE60= =JrNV -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Hi all,

I guess the digital-7.1 corresponds to HBR, and it's a special setup. Meanwhile 5.1 output he has tried is likely the LPCM, so both are in a completely differently manner.

Thank you, that sounds like a good explanation for my first issue.

For the other problem, that seems to be some kind of HDMI handshake related issue to me. I have done some more research and found similar problems like [0]. Their solution to enable a pulseaudio loopback seemed to improve the situation at first; at least during the last two hours, the problem did not occur as often as it did before (without explicitly provoking it), but it occurred though.

In addition, I have disabled the power save options of the snd_hda_intel module:

options snd_hda_intel power_save=0 power_save_controller=N

This however does not seem to have any impact on the problem at all.

I have also found a way to reliably reproduce the problem by muting and immediately unmuting the output in alsamixer having some audio running - -- this way, the output gets silenced for a few seconds a moment after the unmuting almost always.

Is the above solution using the pulseaudio loopback module not enough to prevent handshake issues? Do handshake issues sound suitable at all? Do you have any other ideas where the problem may lies?

Regards, Pascal

[0] https://ubuntuforums.org/showthread.php?t=2215224&p=13117108#post1311710 8

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Hi Takashi,

It's a general problem with many digital receivers. When the stream stops, a digital receiver turn itself off until it re-receives a new stream. And this on/off takes a few seconds.

Thus, you must not stop the stream, but you'd need to keep sending the silent stream even if you stop a playback.

Thank you for your explanation.

I have made sure that the following process is always running when pulseaudio is:

play -n -c1 synth sin gain -100 > /dev/null 2>&1 &

This way, there is always a stream that never stops. The problem of the silent second after starting new audio is solved by that. (I have made sure that the correct output card is used.)

However, every few minutes, the stream still seems to be gone for half a second; even during active additional audio playback (as well as the above sox command), the audio output is silenced for a second and the icons on my receiver are gone meanwhile. Though, pulseaudio does have an output stream all the time without any pause. So there seems to be some other place where the outgoing DP MST stream is lost, delayed or interrupted causing this issue.

During the last few hours, the period of this disruption has been quite consistent between every 4 and 6 minutes.

Do you have any other ideas what might cause this or where parts of the stream could get lost?

Regards, Pascal

On Thu, May 25, 2017 at 1:21 AM, Michael Forney mforney@mforney.org wrote:

Hi,

I recently updated my kernel to 4.11, and am experiencing similar problems as Pascal. I have a Skylake processor and DP output hooked up with a DP to HDMI cable to an Onkyo SR-606 receiver.

I can't get audio to work at all through my receiver anymore. I tried both DTS and PCM audio files. I bisected it to the above mentioned commit 9152085defb6426ce8f9989ca27e4450daefbd89 (ALSA: hda - add DP MST audio support).

...

...

Do you know if the DP MST audio mode is used in your case?

I don't know what DP MST is or how to tell if I'm using it. However, I noticed that when it does work, `aplay -L` gives me

hdmi:CARD=PCH,DEV=0 HDA Intel PCH, HDMI 0 HDMI Audio Output hdmi:CARD=PCH,DEV=1 HDA Intel PCH, HDMI 1 HDMI Audio Output

and when it doesn't, I get

hdmi:CARD=PCH,DEV=0 HDA Intel PCH, Generic Digital HDMI Audio Output

Well, I noticed in my dmesg log for 4.11:

<4>[ 1.201789] snd_hda_intel 0000:00:1f.3: Too many HDMI devices <4>[ 1.201790] snd_hda_intel 0000:00:1f.3: Consider building the kernel with CONFIG_SND_DYNAMIC_MINORS=y <4>[ 1.201792] snd_hda_intel 0000:00:1f.3: Too many HDMI devices <4>[ 1.201794] snd_hda_intel 0000:00:1f.3: Consider building the kernel with CONFIG_SND_DYNAMIC_MINORS=y <4>[ 1.201795] snd_hda_intel 0000:00:1f.3: Too many HDMI devices <4>[ 1.201797] snd_hda_intel 0000:00:1f.3: Consider building the kernel with CONFIG_SND_DYNAMIC_MINORS=y <3>[ 1.202668] snd_hda_intel 0000:00:1f.3: control 3:0:0:ELD:0 is already present <4>[ 1.202737] snd_hda_codec_hdmi: probe of hdaudioC0D2 failed with error -16 <4>[ 1.204335] snd_hda_intel 0000:00:1f.3: Too many HDMI devices <4>[ 1.204337] snd_hda_intel 0000:00:1f.3: Consider building the kernel with CONFIG_SND_DYNAMIC_MINORS=y <4>[ 1.204338] snd_hda_intel 0000:00:1f.3: Too many HDMI devices <4>[ 1.204340] snd_hda_intel 0000:00:1f.3: Consider building the kernel with CONFIG_SND_DYNAMIC_MINORS=y <4>[ 1.204341] snd_hda_intel 0000:00:1f.3: Too many HDMI devices <4>[ 1.204343] snd_hda_intel 0000:00:1f.3: Consider building the kernel with CONFIG_SND_DYNAMIC_MINORS=y <3>[ 1.205412] snd_hda_intel 0000:00:1f.3: control 3:0:0:ELD:0 is already present <4>[ 1.205464] snd_hda_codec_hdmi: probe of hdaudioC0D2 failed with error -16 <6>[ 1.205644] snd_hda_codec_generic hdaudioC0D2: ignore pin 0x7, too many assigned pins <6>[ 1.205648] snd_hda_codec_generic hdaudioC0D2: autoconfig for Generic: line_outs=0 (0x0/0x0/0x0/0x0/0x0) type:line <6>[ 1.205651] snd_hda_codec_generic hdaudioC0D2: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) <6>[ 1.205653] snd_hda_codec_generic hdaudioC0D2: hp_outs=0 (0x0/0x0/0x0/0x0/0x0) <6>[ 1.205655] snd_hda_codec_generic hdaudioC0D2: mono: mono_out=0x0 <6>[ 1.205656] snd_hda_codec_generic hdaudioC0D2: dig-out=0x5/0x6 <6>[ 1.205658] snd_hda_codec_generic hdaudioC0D2: inputs: <6>[ 1.207882] input: HDA Intel PCH Mic as /devices/pci0000:00/0000:00:1f.3/sound/card0/input4 <6>[ 1.207979] input: HDA Intel PCH Front Headphone as /devices/pci0000:00/0000:00:1f.3/sound/card0/input5 <6>[ 1.208070] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input6 <6>[ 1.208158] input: HDA Intel PCH HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input7 <6>[ 1.208246] input: HDA Intel PCH HDMI/DP as /devices/pci0000:00/0000:00:1f.3/sound/card0/input8 <6>[ 1.208335] input: HDA Intel PCH HDMI/DP as /devices/pci0000:00/0000:00:1f.3/sound/card0/input9 <6>[ 1.208441] input: HDA Intel PCH HDMI as /devices/pci0000:00/0000:00:1f.3/sound/card0/input12 <6>[ 1.208582] input: HDA Intel PCH HDMI as /devices/pci0000:00/0000:00:1f.3/sound/card0/input13 <4>[ 1.208700] ------------[ cut here ]------------ <4>[ 1.208708] WARNING: CPU: 0 PID: 43 at fs/proc/generic.c:346 proc_register+0xe9/0x110 <4>[ 1.208709] proc_dir_entry 'card0/eld#2.0' already registered <4>[ 1.208710] Modules linked in: <4>[ 1.208715] CPU: 0 PID: 43 Comm: kworker/0:1 Not tainted 4.11.3+ #41 <4>[ 1.208716] Hardware name: HP HP EliteDesk 800 G2 DM 35W/8055, BIOS N21 Ver. 02.14 04/28/2016 <4>[ 1.208721] Workqueue: events azx_probe_work <4>[ 1.208723] Call Trace: <4>[ 1.208729] dump_stack+0x4d/0x66 <4>[ 1.208733] __warn+0xc6/0xe0 <4>[ 1.208737] warn_slowpath_fmt+0x46/0x50 <4>[ 1.208742] proc_register+0xe9/0x110 <4>[ 1.208746] proc_create_data+0x71/0xc0 <4>[ 1.208750] snd_info_register+0x66/0xd0 <4>[ 1.208753] snd_info_register_recursive+0x5b/0x70 <4>[ 1.208756] snd_info_register_recursive+0x46/0x70 <4>[ 1.208759] snd_info_card_register+0x25/0xa0 <4>[ 1.208764] snd_card_register+0x140/0x190 <4>[ 1.208769] ? device_attach+0xb/0x10 <4>[ 1.208773] ? snd_hda_codec_configure+0xb1/0x120 <4>[ 1.208776] azx_probe_work+0x47d/0x860 <4>[ 1.208778] ? azx_probe_work+0x47d/0x860 <4>[ 1.208783] process_one_work+0x1ec/0x480 <4>[ 1.208787] worker_thread+0x43/0x4d0 <4>[ 1.208790] kthread+0x104/0x140 <4>[ 1.208794] ? process_one_work+0x480/0x480 <4>[ 1.208797] ? kthread_create_on_node+0x40/0x40 <4>[ 1.208802] ret_from_fork+0x29/0x40 <4>[ 1.208805] ---[ end trace 538d7309f1b9646f ]---

So I added CONFIG_SND_DYNAMIC_MINORS=y as suggested (previously it was disabled based on the help text). That seemed to do the trick. However, the `proc_dir_entry 'card0/eld#2.0' already registered` warning seems like it could be a bug despite this.

I guess the problem was this new MST feature means that now I have 5 HDMI outputs showing up, which is too many.

Sorry for the noise.