[pulseaudio-tickets] [Bug 95055] pulseaudio blocked in kernel

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=95055

--- Comment #25 from Brian J. Murrell  ---
(In reply to Alexander E. Patrakov from comment #24)
> 
> No, reproducing the bug with amixer was enough.

OK.  Great.  It did end up returning, eventually, FWIW:

Simple mixer control 'IEC958',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'IEC958',1
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'IEC958',2
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [on]

> I am still waiting for the test result with nouveau.runpm=0 to complete the
> evidence.

$ cat /proc/cmdline 
BOOT_IMAGE=/vmlinuz-4.4.7-300.fc23.x86_64 root=/dev/mapper/fedora_laptop-root
ro rd.lvm.lv=fedora_laptop/boot rd.lvm.lv=fedora_laptop/root
rd.lvm.lv=fedora_laptop/swap rhgb quiet libata.allow_tpm=1 LANG=en_CA.UTF-8
nouveau.runpm=0
$ amixer -c2
[ returned right away with: ]
Simple mixer control 'Speaker',0
  Capabilities: pvolume pvolume-joined pswitch pswitch-joined
  Playback channels: Mono
  Limits: Playback 0 - 704
  Mono: Playback 704 [100%] [3.00dB] [on]
Simple mixer control 'Bass',0
  Capabilities: volume volume-joined
  Playback channels: Mono
  Capture channels: Mono
  Limits: 0 - 48
  Mono: 24 [50%]
Simple mixer control 'Treble',0
  Capabilities: volume volume-joined
  Playback channels: Mono
  Capture channels: Mono
  Limits: 0 - 48
  Mono: 24 [50%]
Simple mixer control 'Mic',0
  Capabilities: pvolume pvolume-joined cvolume cvolume-joined pswitch
pswitch-joined cswitch cswitch-joined
  Playback channels: Mono
  Capture channels: Mono
  Limits: Playback 0 - 656 Capture 0 - 15
  Mono: Playback 368 [56%] [-18.00dB] [on] Capture 15 [100%] [31.00dB] [on]

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
pulseaudio-bugs mailing list
pulseaudio-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs

[pulseaudio-tickets] [Bug 95055] pulseaudio blocked in kernel

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=95055

--- Comment #24 from Alexander E. Patrakov  ---
(In reply to Brian J. Murrell from comment #23)
> (In reply to Alexander E. Patrakov from comment #20)
> > Please verify (without the above parameter) whether this command also gets
> > blocked in the kernel. Run it repeatedly just in case.
> > 
> > amixer -c2
> 
> I only had to run it once:
> $ amixer -c2
> [ didn't return]
> $ ps axf | grep amixer
> 27202 pts/1D+ 0:00  |   \_ amixer -c2
> 
> Here's the stack trace of it:



> > Also try:
> > 
> > alsamixer -c2
> > 
> > and mute/unmute various spdifs repeatedly.
> > 
> > Finally:
> > 
> > time pasuspender -- aplay -d 5 -D hdmi:2 -f dat /dev/zero
> 
> Do you still want the above, given that amixer has blocked in the kernel? 
> If so, I assume you want those if/when amixer does finally return?

No, reproducing the bug with amixer was enough.

I am still waiting for the test result with nouveau.runpm=0 to complete the
evidence.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
pulseaudio-bugs mailing list
pulseaudio-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs

[pulseaudio-tickets] [Bug 95055] pulseaudio blocked in kernel

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=95055

--- Comment #23 from Brian J. Murrell  ---
(In reply to Raymond from comment #19)
> ftp://download.nvidia.com/XFree86/gpu-hdmi-audio-document/gpu-hdmi-audio.
> html#_verify_your_eld_is_validPorts
> 
> 
>   hdmi-output-0: HDMI / DisplayPort (priority: 5900, latency 
> offset: 0 usec,
> available)
>   Properties:
>   device.icon_name = "video-display"
>   device.product.name = "24MP76"
>   Part of profile(s): output:hdmi-stereo
> 
> 
> 
> did your graphic driver get the correct EDID of your LG 24MP76 and pass ELD
> to audio driver ?

I don't (usually) have any monitors connected to the HDMI.  That must have been
a/the one time I did to see if having a monitor on the HDMI port made the
problem any better or worse.

(In reply to Alexander E. Patrakov from comment #20)
> 
> ...and there are no monitors connected to the NVidia GPU. So maybe it is
> powered down. Try to disable this by adding this parameter to the kernel
> command line:
> 
> nouveau.runpm=0

OK.  That will take effect on my next reboot.

> Anyway, this is a kernel bug, not something that can be fixed in PulseAudio.
> All we can do here is to gather some evidence.

Happy to help with that in any way I can.

> Please verify (without the above parameter) whether this command also gets
> blocked in the kernel. Run it repeatedly just in case.
> 
> amixer -c2

I only had to run it once:
$ amixer -c2
[ didn't return]
$ ps axf | grep amixer
27202 pts/1D+ 0:00  |   \_ amixer -c2

Here's the stack trace of it:

 taskPC stack   pid father
amixer  D 8802f995bb98 0 27202   3824 0x
8802f995bb98 88049d6cda00 88046a3b9e00 8802f995c000
8802f995bbd0 8804afb0e080 8804afb0e080 88049c17a000
8802f995bbb0 8179cf95 00010b2a9d8b 8802f995bc60
Call Trace:
[] schedule+0x35/0x80
[] schedule_timeout+0x123/0x270
[] ? trace_event_raw_event_tick_stop+0x120/0x120
[] ? _raw_spin_unlock_irqrestore+0xe/0x10
[] snd_power_wait+0xb5/0x110 [snd]
[] ? wake_up_q+0x70/0x70
[] snd_ctl_elem_info_user+0x61/0xf0 [snd]
[] snd_ctl_ioctl+0x5ec/0x6c0 [snd]
[] ? selinux_file_ioctl+0x10c/0x1c0
[] do_vfs_ioctl+0x298/0x480
[] ? security_file_ioctl+0x43/0x60
[] SyS_ioctl+0x79/0x90
[] entry_SYSCALL_64_fastpath+0x12/0x71

> Also try:
> 
> alsamixer -c2
> 
> and mute/unmute various spdifs repeatedly.
> 
> Finally:
> 
> time pasuspender -- aplay -d 5 -D hdmi:2 -f dat /dev/zero

Do you still want the above, given that amixer has blocked in the kernel?  If
so, I assume you want those if/when amixer does finally return?

(In reply to Raymond from comment #22)
> https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/pci/
> hda/hda_eld.c
> 
> do you have any output of snd_hdmi_print_eld_info

How/where would I get that?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
pulseaudio-bugs mailing list
pulseaudio-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs

[pulseaudio-tickets] [Bug 93946] Changing device profile to HDMI is reset to default after monitor goes into powersave

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=93946

--- Comment #58 from Tanu Kaskinen  ---
(In reply to Arun Raghavan from comment #57)
> My primary concern with this patch series is that it is very common to plug
> in multiple HDMI devices to a single laptop (monitors, projectors, ...), and
> it appears that a preference to route to a single device ends up applying to
> all devices.
> 
> David had mentioned that this *may* be a problem. I'd go as far as to say
> that this is definitely a problem.

A worse problem than what my patches fix? I don't think so.

> So as I understand it, we were looking at solving two problems:
> 
> 1. Non-existent speakers when there is a speaker control

My patches don't aim at solving that.

> 2. DPMS causing an HDMI unplug
> 
> For the first, I concur with David about this not being an issue we should
> try to solve, and we should let underlying layers fix this properly. *Maybe*
> we could look at having a pavucontrol option to mark a system as not having
> internal speakers (and store this on the card in some way).
> 
> For the second, I don't have a good solution. Yes, it would be a _lot_
> better to be able to distinguish between the DPMS and unplugged states.
> There seemed to be a suggestion that this is possible at the graphics driver
> level. Is that true?

I don't know. Was it suggested in this bug thread? I tried to search for
"driver", "kernel" and "graphics", and I didn't find a place where that would
have been suggested.

> As an alternative, it may make sense to at least tie the preferred port
> setting with the corresponding device names from ELDs. That would prevent us
> from explicitly having to route to and away from every HDMI device
> explicitly. It's still not great since ELDs lie, and it's common to have
> multiple monitors of the same type being connected to (e.g. an office with
> homogenous monitor setups, but you only have headphones connected to your
> own workstation).

Creating separate ports based on ELD seems like an improvement for some later
time.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
pulseaudio-bugs mailing list
pulseaudio-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs