[alsa-devel] pulseaudio fails to start with kernel 4.11, caused by new snd_hdmi_lpe_audio module)
Hi,
Lately I've been working on fixing various issues people are having with baytrail / cherrytrail devices. One thing I noticed when moving my testing / development to 4.11 is that pulseaudio does not work (it aborts while starting) this seemed to be caused by the new snd_hdmi_lpe_audio module. If I blacklist that all is fine. Any idea what is causing this ?
Regards,
Hans
On Mon, 20 Mar 2017 12:42:58 +0100, Hans de Goede wrote:
Hi,
Lately I've been working on fixing various issues people are having with baytrail / cherrytrail devices. One thing I noticed when moving my testing / development to 4.11 is that pulseaudio does not work (it aborts while starting) this seemed to be caused by the new snd_hdmi_lpe_audio module. If I blacklist that all is fine. Any idea what is causing this ?
I noticed it once, too, but I had no time to check further. More interestingly, PA works fine when LPE audio is the single driver (i.e. blacklist Intel SST instead), too. So it's more likely a bug in PA.
What happens when you modprobe LPE audio driver after starting the session? If it kills PA, we can debug more easily :)
Takashi
On 3/20/17 4:52 AM, Takashi Iwai wrote:
On Mon, 20 Mar 2017 12:42:58 +0100, Hans de Goede wrote:
Hi,
Lately I've been working on fixing various issues people are having with baytrail / cherrytrail devices. One thing I noticed when moving my testing / development to 4.11 is that pulseaudio does not work (it aborts while starting) this seemed to be caused by the new snd_hdmi_lpe_audio module. If I blacklist that all is fine. Any idea what is causing this ?
I noticed it once, too, but I had no time to check further. More interestingly, PA works fine when LPE audio is the single driver (i.e. blacklist Intel SST instead), too. So it's more likely a bug in PA.
What happens when you modprobe LPE audio driver after starting the session? If it kills PA, we can debug more easily :)
I've seen this as well, I could get either one of the two but not both, could this be due to the fact that one set of mixers is configured with UCM and the other driver isn't configured by UCM?
On Tue, 21 Mar 2017 00:09:22 +0100, Pierre-Louis Bossart wrote:
On 3/20/17 4:52 AM, Takashi Iwai wrote:
On Mon, 20 Mar 2017 12:42:58 +0100, Hans de Goede wrote:
Hi,
Lately I've been working on fixing various issues people are having with baytrail / cherrytrail devices. One thing I noticed when moving my testing / development to 4.11 is that pulseaudio does not work (it aborts while starting) this seemed to be caused by the new snd_hdmi_lpe_audio module. If I blacklist that all is fine. Any idea what is causing this ?
I noticed it once, too, but I had no time to check further. More interestingly, PA works fine when LPE audio is the single driver (i.e. blacklist Intel SST instead), too. So it's more likely a bug in PA.
What happens when you modprobe LPE audio driver after starting the session? If it kills PA, we can debug more easily :)
I've seen this as well, I could get either one of the two but not both, could this be due to the fact that one set of mixers is configured with UCM and the other driver isn't configured by UCM?
No idea, and I had still no time to check (still processing the pile of pending mails and other bugs :). Let me add PA guys to Cc.
thanks,
Takashi
On Tue, 21 Mar 2017, at 11:10 AM, Takashi Iwai wrote:
On Tue, 21 Mar 2017 00:09:22 +0100, Pierre-Louis Bossart wrote:
On 3/20/17 4:52 AM, Takashi Iwai wrote:
On Mon, 20 Mar 2017 12:42:58 +0100, Hans de Goede wrote:
Hi,
Lately I've been working on fixing various issues people are having with baytrail / cherrytrail devices. One thing I noticed when moving my testing / development to 4.11 is that pulseaudio does not work (it aborts while starting) this seemed to be caused by the new snd_hdmi_lpe_audio module. If I blacklist that all is fine. Any idea what is causing this ?
I noticed it once, too, but I had no time to check further. More interestingly, PA works fine when LPE audio is the single driver (i.e. blacklist Intel SST instead), too. So it's more likely a bug in PA.
What happens when you modprobe LPE audio driver after starting the session? If it kills PA, we can debug more easily :)
I've seen this as well, I could get either one of the two but not both, could this be due to the fact that one set of mixers is configured with UCM and the other driver isn't configured by UCM?
No idea, and I had still no time to check (still processing the pile of pending mails and other bugs :). Let me add PA guys to Cc.
Not sure if anyone here has the hardware and I haven't seen any complaints either -- having a backtrace (or even location of the assert) would be a good start.
Cheers, Arun
Hi,
On 21-03-17 08:54, Arun Raghavan wrote:
On Tue, 21 Mar 2017, at 11:10 AM, Takashi Iwai wrote:
On Tue, 21 Mar 2017 00:09:22 +0100, Pierre-Louis Bossart wrote:
On 3/20/17 4:52 AM, Takashi Iwai wrote:
On Mon, 20 Mar 2017 12:42:58 +0100, Hans de Goede wrote:
Hi,
Lately I've been working on fixing various issues people are having with baytrail / cherrytrail devices. One thing I noticed when moving my testing / development to 4.11 is that pulseaudio does not work (it aborts while starting) this seemed to be caused by the new snd_hdmi_lpe_audio module. If I blacklist that all is fine. Any idea what is causing this ?
I noticed it once, too, but I had no time to check further. More interestingly, PA works fine when LPE audio is the single driver (i.e. blacklist Intel SST instead), too. So it's more likely a bug in PA.
What happens when you modprobe LPE audio driver after starting the session? If it kills PA, we can debug more easily :)
I've seen this as well, I could get either one of the two but not both, could this be due to the fact that one set of mixers is configured with UCM and the other driver isn't configured by UCM?
No idea, and I had still no time to check (still processing the pile of pending mails and other bugs :). Let me add PA guys to Cc.
Not sure if anyone here has the hardware and I haven't seen any complaints either -- having a backtrace (or even location of the assert) would be a good start.
Ok, this is weird. Since you were asking for more info I tried to collect a backtrace / logs. But what is happening is that after the snd_hdmi_lpe_audio module loads, pulse does its thing and then exits with a message of "killed" in gdb / on the terminal from which I started it. I don't get a chance to get a backtrace in gdb ... So this does feel like a kernel bug to me, normally this sort of "killed" behavior is seen on some kernel oopses...
But dmesg is free of any oopses ?
Anyways here is a log of pulseaudio -v first without the hdmi module and then the module gets probed. Where the log abruptly ends is where I got the "Killed" message on the terminal.
I: [pulseaudio] main.c: setrlimit(RLIMIT_NICE, (31, 31)) failed: Operation not permitted I: [pulseaudio] main.c: setrlimit(RLIMIT_RTPRIO, (9, 9)) failed: Operation not permitted I: [pulseaudio] core-util.c: Successfully gained nice level -11. I: [pulseaudio] main.c: This is PulseAudio 10.0 I: [pulseaudio] main.c: Page size is 4096 bytes I: [pulseaudio] main.c: Machine ID is ea8812c830d64c42bbac77fda93c3850. I: [pulseaudio] main.c: Session ID is 2. I: [pulseaudio] main.c: Using runtime directory /run/user/1000/pulse. I: [pulseaudio] main.c: Using state directory /home/hans/.config/pulse. I: [pulseaudio] main.c: Using modules directory /usr/lib64/pulse-10.0/modules. I: [pulseaudio] main.c: Running in system mode: no W: [pulseaudio] pid.c: Stale PID file, overwriting. I: [pulseaudio] main.c: System supports high resolution timers I: [pulseaudio] cpu-x86.c: CPU flags: CMOV MMX SSE SSE2 SSE3 SSSE3 SSE4_1 SSE4_2 I: [pulseaudio] svolume_mmx.c: Initialising MMX optimized volume functions. I: [pulseaudio] remap_mmx.c: Initialising MMX optimized remappers. I: [pulseaudio] svolume_sse.c: Initialising SSE2 optimized volume functions. I: [pulseaudio] remap_sse.c: Initialising SSE2 optimized remappers. I: [pulseaudio] sconv_sse.c: Initialising SSE2 optimized conversions. I: [pulseaudio] svolume_orc.c: Initialising ORC optimized volume functions. I: [pulseaudio] module-device-restore.c: Successfully opened database file '/home/hans/.config/pulse/ea8812c830d64c42bbac77fda93c3850-device-volumes'. I: [pulseaudio] module.c: Loaded "module-device-restore" (index: #0; argument: ""). I: [pulseaudio] module-stream-restore.c: Successfully opened database file '/home/hans/.config/pulse/ea8812c830d64c42bbac77fda93c3850-stream-volumes'. I: [pulseaudio] module.c: Loaded "module-stream-restore" (index: #1; argument: ""). I: [pulseaudio] module-card-restore.c: Successfully opened database file '/home/hans/.config/pulse/ea8812c830d64c42bbac77fda93c3850-card-database'. I: [pulseaudio] module.c: Loaded "module-card-restore" (index: #2; argument: ""). I: [pulseaudio] module.c: Loaded "module-augment-properties" (index: #3; argument: ""). I: [pulseaudio] module.c: Loaded "module-switch-on-port-available" (index: #4; argument: ""). I: [pulseaudio] alsa-ucm.c: UCM available for card chtrt5645 I: [pulseaudio] alsa-ucm.c: Set UCM verb to HiFi I: [pulseaudio] module-alsa-card.c: Found UCM profiles I: [pulseaudio] alsa-ucm.c: Set ucm verb to HiFi I: [pulseaudio] alsa-util.c: snd_pcm_hw_params_set_buffer_size_near() failed: Invalid argument I: [pulseaudio] alsa-util.c: Device hw:chtrt5645 doesn't support 44100 Hz, changed to 48000 Hz. I: [pulseaudio] alsa-util.c: snd_pcm_hw_params_set_buffer_size_near() failed: Invalid argument I: [pulseaudio] alsa-util.c: Device hw:chtrt5645 doesn't support 44100 Hz, changed to 48000 Hz. I: [pulseaudio] alsa-util.c: Successfully attached to mixer 'hw:chtrt5645' I: [pulseaudio] alsa-ucm.c: UCM jack Headphones has_control=0 I: [pulseaudio] alsa-ucm.c: UCM jack Speaker has_control=0 I: [pulseaudio] alsa-util.c: Successfully attached to mixer 'hw:chtrt5645' I: [pulseaudio] alsa-ucm.c: UCM jack Headset Mic has_control=1 I: [pulseaudio] alsa-ucm.c: UCM jack DMic has_control=0 I: [pulseaudio] alsa-ucm.c: UCM jack Mic has_control=0 I: [pulseaudio] module-card-restore.c: Restoring port latency offsets for card alsa_card.platform-cht-bsw-rt5645. I: [pulseaudio] alsa-util.c: Successfully attached to mixer 'hw:0' I: [pulseaudio] card.c: Created 0 "alsa_card.platform-cht-bsw-rt5645" I: [pulseaudio] alsa-ucm.c: Set UCM verb to HiFi I: [pulseaudio] alsa-util.c: Cannot disable ALSA period wakeups I: [pulseaudio] alsa-util.c: Device hw:chtrt5645 doesn't support 44100 Hz, changed to 48000 Hz. I: [pulseaudio] alsa-util.c: ALSA period wakeups were not disabled I: [pulseaudio] alsa-sink.c: Successfully opened device hw:chtrt5645. I: [pulseaudio] alsa-sink.c: Selected mapping 'Headphones + Speaker' (HiFi: hw:chtrt5645: sink). I: [pulseaudio] alsa-sink.c: Successfully enabled mmap() mode. I: [pulseaudio] alsa-sink.c: Successfully enabled timer-based scheduling mode. I: [pulseaudio] alsa-ucm.c: ALSA device hw:chtrt5645 roles: (null) I: [pulseaudio] module-device-restore.c: Restoring port for sink sink:alsa_output.platform-cht-bsw-rt5645.HiFi__hw_chtrt5645__sink. W: [pulseaudio] sink.c: Default and alternate sample rates are the same. I: [pulseaudio] sink.c: Created sink 0 "alsa_output.platform-cht-bsw-rt5645.HiFi__hw_chtrt5645__sink" with sample spec s16le 2ch 48000Hz and channel map front-left,front-right I: [pulseaudio] sink.c: alsa.resolution_bits = "16" I: [pulseaudio] sink.c: device.api = "alsa" I: [pulseaudio] sink.c: device.class = "sound" I: [pulseaudio] sink.c: alsa.class = "generic" I: [pulseaudio] sink.c: alsa.subclass = "generic-mix" I: [pulseaudio] sink.c: alsa.name = "" I: [pulseaudio] sink.c: alsa.id = "1" I: [pulseaudio] sink.c: alsa.subdevice = "0" I: [pulseaudio] sink.c: alsa.subdevice_name = "subdevice #0" I: [pulseaudio] sink.c: alsa.device = "0" I: [pulseaudio] sink.c: alsa.card = "0" I: [pulseaudio] sink.c: alsa.card_name = "chtrt5645" I: [pulseaudio] sink.c: alsa.long_card_name = "chtrt5645" I: [pulseaudio] sink.c: alsa.driver_name = "snd_soc_sst_cht_bsw_rt5645" I: [pulseaudio] sink.c: device.bus_path = "platform-cht-bsw-rt5645" I: [pulseaudio] sink.c: sysfs.path = "/devices/pci0000:00/808622A8:00/cht-bsw-rt5645/sound/card0" I: [pulseaudio] sink.c: device.string = "hw:chtrt5645" I: [pulseaudio] sink.c: device.buffering.buffer_size = "384000" I: [pulseaudio] sink.c: device.buffering.fragment_size = "192000" I: [pulseaudio] sink.c: device.access_mode = "mmap+timer" I: [pulseaudio] sink.c: device.profile.name = "HiFi: hw:chtrt5645: sink" I: [pulseaudio] sink.c: device.profile.description = "Headphones + Speaker" I: [pulseaudio] sink.c: device.description = "chtrt5645 Headphones + Speaker" I: [pulseaudio] sink.c: module-udev-detect.discovered = "1" I: [pulseaudio] sink.c: device.icon_name = "audio-card" I: [pulseaudio] source.c: Created source 0 "alsa_output.platform-cht-bsw-rt5645.HiFi__hw_chtrt5645__sink.monitor" with sample spec s16le 2ch 48000Hz and channel map front-left,front-right I: [pulseaudio] source.c: device.description = "Monitor of chtrt5645 Headphones + Speaker" I: [pulseaudio] source.c: device.class = "monitor" I: [pulseaudio] source.c: alsa.card = "0" I: [pulseaudio] source.c: alsa.card_name = "chtrt5645" I: [pulseaudio] source.c: alsa.long_card_name = "chtrt5645" I: [pulseaudio] source.c: alsa.driver_name = "snd_soc_sst_cht_bsw_rt5645" I: [pulseaudio] source.c: device.bus_path = "platform-cht-bsw-rt5645" I: [pulseaudio] source.c: sysfs.path = "/devices/pci0000:00/808622A8:00/cht-bsw-rt5645/sound/card0" I: [pulseaudio] source.c: device.string = "0" I: [pulseaudio] source.c: module-udev-detect.discovered = "1" I: [pulseaudio] source.c: device.icon_name = "audio-card" I: [pulseaudio] alsa-sink.c: Using 2.0 fragments of size 192000 bytes (1000.00ms), buffer size is 384000 bytes (2000.00ms) I: [pulseaudio] alsa-sink.c: Time scheduling watermark is 18.38ms I: [alsa-sink-1] core-util.c: Successfully enabled SCHED_RR scheduling for thread, with priority 5. I: [alsa-sink-1] alsa-sink.c: Starting playback. I: [pulseaudio] alsa-util.c: Cannot disable ALSA period wakeups I: [pulseaudio] alsa-util.c: Device hw:chtrt5645 doesn't support 44100 Hz, changed to 48000 Hz. I: [pulseaudio] alsa-util.c: ALSA period wakeups were not disabled I: [pulseaudio] alsa-source.c: Successfully opened device hw:chtrt5645. I: [pulseaudio] alsa-source.c: Selected mapping 'Headset Microphone + Internal Digital Microphones + Internal Analog Microphones' (HiFi: hw:chtrt5645: source). I: [pulseaudio] alsa-source.c: Successfully enabled mmap() mode. I: [pulseaudio] alsa-source.c: Successfully enabled timer-based scheduling mode. I: [pulseaudio] alsa-ucm.c: ALSA device hw:chtrt5645 roles: (null) W: [pulseaudio] source.c: Default and alternate sample rates are the same. I: [pulseaudio] source.c: Created source 1 "alsa_input.platform-cht-bsw-rt5645.HiFi__hw_chtrt5645__source" with sample spec s16le 2ch 48000Hz and channel map front-left,front-right I: [pulseaudio] source.c: alsa.resolution_bits = "16" I: [pulseaudio] source.c: device.api = "alsa" I: [pulseaudio] source.c: device.class = "sound" I: [pulseaudio] source.c: alsa.class = "generic" I: [pulseaudio] source.c: alsa.subclass = "generic-mix" I: [pulseaudio] source.c: alsa.name = "" I: [pulseaudio] source.c: alsa.id = "3" I: [pulseaudio] source.c: alsa.subdevice = "0" I: [pulseaudio] source.c: alsa.subdevice_name = "subdevice #0" I: [pulseaudio] source.c: alsa.device = "0" I: [pulseaudio] source.c: alsa.card = "0" I: [pulseaudio] source.c: alsa.card_name = "chtrt5645" I: [pulseaudio] source.c: alsa.long_card_name = "chtrt5645" I: [pulseaudio] source.c: alsa.driver_name = "snd_soc_sst_cht_bsw_rt5645" I: [pulseaudio] source.c: device.bus_path = "platform-cht-bsw-rt5645" I: [pulseaudio] source.c: sysfs.path = "/devices/pci0000:00/808622A8:00/cht-bsw-rt5645/sound/card0" I: [pulseaudio] source.c: device.string = "hw:chtrt5645" I: [pulseaudio] source.c: device.buffering.buffer_size = "384000" I: [pulseaudio] source.c: device.buffering.fragment_size = "192000" I: [pulseaudio] source.c: device.access_mode = "mmap+timer" I: [pulseaudio] source.c: device.profile.name = "HiFi: hw:chtrt5645: source" I: [pulseaudio] source.c: device.profile.description = "Headset Microphone + Internal Digital Microphones + Internal Analog Microphones" I: [pulseaudio] source.c: device.description = "chtrt5645 Headset Microphone + Internal Digital Microphones + Internal Analog Microphones" I: [pulseaudio] source.c: module-udev-detect.discovered = "1" I: [pulseaudio] source.c: device.icon_name = "audio-card" I: [pulseaudio] alsa-source.c: Using 2.0 fragments of size 192000 bytes (1000.00ms), buffer size is 384000 bytes (2000.00ms) I: [pulseaudio] alsa-source.c: Time scheduling watermark is 18.38ms I: [alsa-source-3] core-util.c: Successfully enabled SCHED_RR scheduling for thread, with priority 5. I: [alsa-source-3] alsa-source.c: Starting capture. I: [pulseaudio] module.c: Loaded "module-alsa-card" (index: #6; argument: "device_id="0" name="platform-cht-bsw-rt5645" card_name="alsa_card.platform-cht-bsw-rt5645" namereg_fail=false tsched=yes fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes card_properties="module-udev-detect.discovered=1""). I: [pulseaudio] module-udev-detect.c: Card /devices/pci0000:00/808622A8:00/cht-bsw-rt5645/sound/card0 (alsa_card.platform-cht-bsw-rt5645) module loaded. I: [pulseaudio] module-udev-detect.c: Found 1 cards. I: [pulseaudio] module.c: Loaded "module-udev-detect" (index: #5; argument: ""). I: [pulseaudio] module.c: Loaded "module-bluetooth-policy" (index: #7; argument: ""). I: [pulseaudio] module.c: Loaded "module-bluez5-discover" (index: #9; argument: ""). I: [pulseaudio] module.c: Loaded "module-bluetooth-discover" (index: #8; argument: ""). I: [pulseaudio] module.c: Loaded "module-esound-protocol-unix" (index: #10; argument: ""). I: [pulseaudio] module.c: Loaded "module-native-protocol-unix" (index: #11; argument: ""). I: [pulseaudio] module-default-device-restore.c: Restored default sink 'alsa_output.platform-cht-bsw-rt5645.HiFi__hw_chtrt5645__sink'. I: [pulseaudio] module-default-device-restore.c: Restored default source 'alsa_input.platform-cht-bsw-rt5645.HiFi__hw_chtrt5645__source'. I: [pulseaudio] module.c: Loaded "module-default-device-restore" (index: #12; argument: ""). I: [pulseaudio] module.c: Loaded "module-rescue-streams" (index: #13; argument: ""). I: [pulseaudio] module.c: Loaded "module-always-sink" (index: #14; argument: ""). I: [pulseaudio] module.c: Loaded "module-intended-roles" (index: #15; argument: ""). I: [pulseaudio] module.c: Loaded "module-suspend-on-idle" (index: #16; argument: ""). I: [pulseaudio] client.c: Created 0 "Login Session 2" I: [pulseaudio] module.c: Loaded "module-systemd-login" (index: #17; argument: ""). I: [pulseaudio] module.c: Loaded "module-position-event-sounds" (index: #18; argument: ""). I: [pulseaudio] module.c: Loaded "module-role-cork" (index: #19; argument: ""). I: [pulseaudio] module.c: Loaded "module-filter-heuristics" (index: #20; argument: ""). I: [pulseaudio] module.c: Loaded "module-filter-apply" (index: #21; argument: ""). I: [pulseaudio] main.c: Daemon startup complete. I: [pulseaudio] module-suspend-on-idle.c: Source alsa_input.platform-cht-bsw-rt5645.HiFi__hw_chtrt5645__source idle for too long, suspending ... I: [alsa-source-3] alsa-source.c: Device suspended... I: [pulseaudio] module-suspend-on-idle.c: Sink alsa_output.platform-cht-bsw-rt5645.HiFi__hw_chtrt5645__sink idle for too long, suspending ... I: [alsa-sink-1] alsa-sink.c: Device suspended... I: [pulseaudio] (alsa-lib)utils.c: could not open configuration file /usr/share/alsa/ucm/Intel HDMI/DP LPE Audio/Intel HDMI/DP LPE Audio.conf I: [pulseaudio] (alsa-lib)parser.c: error: could not parse configuration for card Intel HDMI/DP LPE Audio I: [pulseaudio] (alsa-lib)main.c: error: failed to import Intel HDMI/DP LPE Audio use case configuration -2 I: [pulseaudio] alsa-ucm.c: UCM not available for card Intel HDMI/DP LPE Audio I: [pulseaudio] (alsa-lib)pcm_hw.c: open '/dev/snd/pcmC1D0c' failed (-2) I: [pulseaudio] alsa-util.c: Error opening PCM device hw:1: No such file or directory I: [pulseaudio] (alsa-lib)conf.c: Unknown parameters 1 I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM front:1 I: [pulseaudio] alsa-util.c: Error opening PCM device front:1: Invalid argument I: [pulseaudio] (alsa-lib)pcm_hw.c: open '/dev/snd/pcmC1D0c' failed (-2) I: [pulseaudio] alsa-util.c: Error opening PCM device hw:1: No such file or directory I: [pulseaudio] (alsa-lib)conf.c: Unknown parameters 1 I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM iec958:1 I: [pulseaudio] alsa-util.c: Error opening PCM device iec958:1: Invalid argument I: [pulseaudio] alsa-util.c: Failed to set hardware parameters on plug:hw:1: Invalid argument I: [pulseaudio] (alsa-lib)conf.c: Unknown parameters 1 I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM front:1 I: [pulseaudio] alsa-util.c: Error opening PCM device front:1: Invalid argument I: [pulseaudio] alsa-util.c: snd_pcm_hw_params_set_buffer_size_near() failed: Invalid argument I: [pulseaudio] alsa-util.c: Successfully attached to mixer 'hw:1' I: [pulseaudio] (alsa-lib)conf.c: Unknown parameters 1 I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM surround21:1 I: [pulseaudio] alsa-util.c: Error opening PCM device surround21:1: Invalid argument I: [pulseaudio] (alsa-lib)conf.c: Unknown parameters 1 I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM surround40:1 I: [pulseaudio] alsa-util.c: Error opening PCM device surround40:1: Invalid argument I: [pulseaudio] (alsa-lib)conf.c: Unknown parameters 1 I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM surround41:1 I: [pulseaudio] alsa-util.c: Error opening PCM device surround41:1: Invalid argument I: [pulseaudio] (alsa-lib)conf.c: Unknown parameters 1 I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM surround50:1 I: [pulseaudio] alsa-util.c: Error opening PCM device surround50:1: Invalid argument I: [pulseaudio] (alsa-lib)conf.c: Unknown parameters 1 I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM surround51:1 I: [pulseaudio] alsa-util.c: Error opening PCM device surround51:1: Invalid argument I: [pulseaudio] (alsa-lib)conf.c: Unknown parameters 1 I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM surround71:1 I: [pulseaudio] alsa-util.c: Error opening PCM device surround71:1: Invalid argument I: [pulseaudio] (alsa-lib)conf.c: Unknown parameters 1 I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM iec958:1 I: [pulseaudio] alsa-util.c: Error opening PCM device iec958:1: Invalid argument I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM a52:1 I: [pulseaudio] alsa-util.c: Error opening PCM device a52:1: No such file or directory I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM a52:1 I: [pulseaudio] alsa-util.c: Error opening PCM device a52:1: No such file or directory I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM dca:1 I: [pulseaudio] alsa-util.c: Error opening PCM device dca:1: No such file or directory I: [pulseaudio] (alsa-lib)conf.c: Unknown parameters 1 I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM hdmi:1 I: [pulseaudio] alsa-util.c: Error opening PCM device hdmi:1: Invalid argument I: [pulseaudio] (alsa-lib)conf.c: Unknown parameters 1 I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM hdmi:1 I: [pulseaudio] alsa-util.c: Error opening PCM device hdmi:1: Invalid argument I: [pulseaudio] (alsa-lib)conf.c: Unknown parameters 1 I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM hdmi:1 I: [pulseaudio] alsa-util.c: Error opening PCM device hdmi:1: Invalid argument I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM dcahdmi:1 I: [pulseaudio] alsa-util.c: Error opening PCM device dcahdmi:1: No such file or directory I: [pulseaudio] (alsa-lib)conf.c: Unknown parameters 1,1 I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM hdmi:1,1 I: [pulseaudio] alsa-util.c: Error opening PCM device hdmi:1,1: Invalid argument I: [pulseaudio] (alsa-lib)conf.c: Unknown parameters 1,1 I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM hdmi:1,1 I: [pulseaudio] alsa-util.c: Error opening PCM device hdmi:1,1: Invalid argument I: [pulseaudio] (alsa-lib)conf.c: Unknown parameters 1,1 I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM hdmi:1,1 I: [pulseaudio] alsa-util.c: Error opening PCM device hdmi:1,1: Invalid argument I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM dcahdmi:1,1 I: [pulseaudio] alsa-util.c: Error opening PCM device dcahdmi:1,1: No such file or directory I: [pulseaudio] (alsa-lib)conf.c: Unknown parameters 1,2 I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM hdmi:1,2 I: [pulseaudio] alsa-util.c: Error opening PCM device hdmi:1,2: Invalid argument I: [pulseaudio] (alsa-lib)conf.c: Unknown parameters 1,2 I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM hdmi:1,2 I: [pulseaudio] alsa-util.c: Error opening PCM device hdmi:1,2: Invalid argument I: [pulseaudio] (alsa-lib)conf.c: Unknown parameters 1,2 I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM hdmi:1,2 I: [pulseaudio] alsa-util.c: Error opening PCM device hdmi:1,2: Invalid argument I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM dcahdmi:1,2 I: [pulseaudio] alsa-util.c: Error opening PCM device dcahdmi:1,2: No such file or directory I: [pulseaudio] (alsa-lib)conf.c: Unknown parameters 1,3 I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM hdmi:1,3 I: [pulseaudio] alsa-util.c: Error opening PCM device hdmi:1,3: Invalid argument I: [pulseaudio] (alsa-lib)conf.c: Unknown parameters 1,3 I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM hdmi:1,3 I: [pulseaudio] alsa-util.c: Error opening PCM device hdmi:1,3: Invalid argument I: [pulseaudio] (alsa-lib)conf.c: Unknown parameters 1,3 I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM hdmi:1,3 I: [pulseaudio] alsa-util.c: Error opening PCM device hdmi:1,3: Invalid argument I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM dcahdmi:1,3 I: [pulseaudio] alsa-util.c: Error opening PCM device dcahdmi:1,3: No such file or directory I: [pulseaudio] (alsa-lib)conf.c: Unknown parameters 1,4 I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM hdmi:1,4 I: [pulseaudio] alsa-util.c: Error opening PCM device hdmi:1,4: Invalid argument I: [pulseaudio] (alsa-lib)conf.c: Unknown parameters 1,4 I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM hdmi:1,4 I: [pulseaudio] alsa-util.c: Error opening PCM device hdmi:1,4: Invalid argument I: [pulseaudio] (alsa-lib)conf.c: Unknown parameters 1,4 I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM hdmi:1,4 I: [pulseaudio] alsa-util.c: Error opening PCM device hdmi:1,4: Invalid argument I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM dcahdmi:1,4 I: [pulseaudio] alsa-util.c: Error opening PCM device dcahdmi:1,4: No such file or directory I: [pulseaudio] (alsa-lib)conf.c: Unknown parameters 1,5 I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM hdmi:1,5 I: [pulseaudio] alsa-util.c: Error opening PCM device hdmi:1,5: Invalid argument I: [pulseaudio] (alsa-lib)conf.c: Unknown parameters 1,5 I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM hdmi:1,5 I: [pulseaudio] alsa-util.c: Error opening PCM device hdmi:1,5: Invalid argument I: [pulseaudio] (alsa-lib)conf.c: Unknown parameters 1,5 I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM hdmi:1,5 I: [pulseaudio] alsa-util.c: Error opening PCM device hdmi:1,5: Invalid argument I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM dcahdmi:1,5 I: [pulseaudio] alsa-util.c: Error opening PCM device dcahdmi:1,5: No such file or directory I: [pulseaudio] (alsa-lib)conf.c: Unknown parameters 1,6 I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM hdmi:1,6 I: [pulseaudio] alsa-util.c: Error opening PCM device hdmi:1,6: Invalid argument I: [pulseaudio] (alsa-lib)conf.c: Unknown parameters 1,6 I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM hdmi:1,6 I: [pulseaudio] alsa-util.c: Error opening PCM device hdmi:1,6: Invalid argument I: [pulseaudio] (alsa-lib)conf.c: Unknown parameters 1,6 I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM hdmi:1,6 I: [pulseaudio] alsa-util.c: Error opening PCM device hdmi:1,6: Invalid argument I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM dcahdmi:1,6 I: [pulseaudio] alsa-util.c: Error opening PCM device dcahdmi:1,6: No such file or directory I: [pulseaudio] (alsa-lib)conf.c: Unknown parameters 1,7 I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM hdmi:1,7 I: [pulseaudio] alsa-util.c: Error opening PCM device hdmi:1,7: Invalid argument I: [pulseaudio] (alsa-lib)conf.c: Unknown parameters 1,7 I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM hdmi:1,7 I: [pulseaudio] alsa-util.c: Error opening PCM device hdmi:1,7: Invalid argument I: [pulseaudio] (alsa-lib)conf.c: Unknown parameters 1,7 I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM hdmi:1,7 I: [pulseaudio] alsa-util.c: Error opening PCM device hdmi:1,7: Invalid argument I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM dcahdmi:1,7 I: [pulseaudio] alsa-util.c: Error opening PCM device dcahdmi:1,7: No such file or directory I: [pulseaudio] (alsa-lib)pcm_hw.c: open '/dev/snd/pcmC1D0c' failed (-2) I: [pulseaudio] alsa-util.c: Error opening PCM device hw:1: No such file or directory I: [pulseaudio] module-card-restore.c: Restoring port latency offsets for card alsa_card.pci-0000_00_02.0-platform-hdmi-lpe-audio. I: [pulseaudio] card.c: Created 1 "alsa_card.pci-0000_00_02.0-platform-hdmi-lpe-audio" I: [pulseaudio] (alsa-lib)conf.c: Unknown parameters 1 I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM front:1 I: [pulseaudio] alsa-util.c: Error opening PCM device front:1: Invalid argument I: [pulseaudio] alsa-util.c: Trying to disable ALSA period wakeups, using timers only I: [pulseaudio] alsa-util.c: snd_pcm_hw_params_set_buffer_size_near() failed: Invalid argument I: [pulseaudio] alsa-util.c: ALSA period wakeups disabled I: [pulseaudio] alsa-sink.c: Successfully opened device hw:1. I: [pulseaudio] alsa-sink.c: Selected mapping 'Analog Stereo' (analog-stereo). I: [pulseaudio] alsa-sink.c: Successfully enabled mmap() mode. I: [pulseaudio] alsa-sink.c: Successfully enabled timer-based scheduling mode. I: [pulseaudio] alsa-util.c: Successfully attached to mixer 'hw:1' I: [pulseaudio] sink.c: Created sink 1 "alsa_output.pci-0000_00_02.0-platform-hdmi-lpe-audio.analog-stereo" with sample spec s16le 2ch 44100Hz and channel map front-left,front-right I: [pulseaudio] sink.c: alsa.resolution_bits = "16" I: [pulseaudio] sink.c: device.api = "alsa" I: [pulseaudio] sink.c: device.class = "sound" I: [pulseaudio] sink.c: alsa.class = "generic" I: [pulseaudio] sink.c: alsa.subclass = "generic-mix" I: [pulseaudio] sink.c: alsa.name = "Intel HDMI/DP LPE Audio" I: [pulseaudio] sink.c: alsa.id = "HdmiLpeAudio" I: [pulseaudio] sink.c: alsa.subdevice = "0" I: [pulseaudio] sink.c: alsa.subdevice_name = "subdevice #0" I: [pulseaudio] sink.c: alsa.device = "0" I: [pulseaudio] sink.c: alsa.card = "1" I: [pulseaudio] sink.c: alsa.card_name = "Intel HDMI/DP LPE Audio" I: [pulseaudio] sink.c: alsa.long_card_name = "Intel HDMI/DP LPE Audio" I: [pulseaudio] sink.c: alsa.driver_name = "snd_hdmi_lpe_audio" I: [pulseaudio] sink.c: device.bus_path = "pci-0000:00:02.0-platform-hdmi-lpe-audio" I: [pulseaudio] sink.c: sysfs.path = "/devices/pci0000:00/0000:00:02.0/hdmi-lpe-audio/sound/card1" I: [pulseaudio] sink.c: device.bus = "pci" I: [pulseaudio] sink.c: device.vendor.id = "8086" I: [pulseaudio] sink.c: device.vendor.name = "Intel Corporation" I: [pulseaudio] sink.c: device.product.id = "22b0" I: [pulseaudio] sink.c: device.product.name = "Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series PCI Configuration Registers" I: [pulseaudio] sink.c: device.string = "hw:1" I: [pulseaudio] sink.c: device.buffering.buffer_size = "352832" I: [pulseaudio] sink.c: device.buffering.fragment_size = "352832" I: [pulseaudio] sink.c: device.access_mode = "mmap+timer" I: [pulseaudio] sink.c: device.profile.name = "analog-stereo" I: [pulseaudio] sink.c: device.profile.description = "Analog Stereo" I: [pulseaudio] sink.c: device.description = "Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series PCI Configuration Registers Analog Stereo" I: [pulseaudio] sink.c: module-udev-detect.discovered = "1" I: [pulseaudio] sink.c: device.icon_name = "audio-card-pci" I: [pulseaudio] source.c: Created source 2 "alsa_output.pci-0000_00_02.0-platform-hdmi-lpe-audio.analog-stereo.monitor" with sample spec s16le 2ch 44100Hz and channel map front-left,front-right I: [pulseaudio] source.c: device.description = "Monitor of Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series PCI Configuration Registers Analog Stereo" I: [pulseaudio] source.c: device.class = "monitor" I: [pulseaudio] source.c: alsa.card = "1" I: [pulseaudio] source.c: alsa.card_name = "Intel HDMI/DP LPE Audio" I: [pulseaudio] source.c: alsa.long_card_name = "Intel HDMI/DP LPE Audio" I: [pulseaudio] source.c: alsa.driver_name = "snd_hdmi_lpe_audio" I: [pulseaudio] source.c: device.bus_path = "pci-0000:00:02.0-platform-hdmi-lpe-audio" I: [pulseaudio] source.c: sysfs.path = "/devices/pci0000:00/0000:00:02.0/hdmi-lpe-audio/sound/card1" I: [pulseaudio] source.c: device.bus = "pci" I: [pulseaudio] source.c: device.vendor.id = "8086" I: [pulseaudio] source.c: device.vendor.name = "Intel Corporation" I: [pulseaudio] source.c: device.product.id = "22b0" I: [pulseaudio] source.c: device.product.name = "Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series PCI Configuration Registers" I: [pulseaudio] source.c: device.string = "1" I: [pulseaudio] source.c: module-udev-detect.discovered = "1" I: [pulseaudio] source.c: device.icon_name = "audio-card-pci" 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) I: [pulseaudio] module.c: Loaded "module-alsa-card" (index: #22; argument: "device_id="1" name="pci-0000_00_02.0-platform-hdmi-lpe-audio" card_name="alsa_card.pci-0000_00_02.0-platform-hdmi-lpe-audio" namereg_fail=false tsched=yes fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes card_properties="module-udev-detect.discovered=1""). I: [pulseaudio] module-udev-detect.c: Card /devices/pci0000:00/0000:00:02.0/hdmi-lpe-audio/sound/card1 (alsa_card.pci-0000_00_02.0-platform-hdmi-lpe-audio) module loaded. I: [alsa-sink-HdmiLpeAudio] alsa-sink.c: Starting playback. I: [alsa-sink-HdmiLpeAudio] alsa-sink.c: Starting playback. I: [alsa-sink-HdmiLpeAudio] alsa-sink.c: Starting playback. I: [alsa-sink-HdmiLpeAudio] alsa-sink.c: Starting playback. I: [alsa-sink-HdmiLpeAudio] alsa-sink.c: Starting playback. I: [alsa-sink-HdmiLpeAudio] alsa-sink.c: Starting playback.
Note I'm seeing this on multiple Cherry Trail devices as well as on a Bay Trail Asus T100TA (if I remember correctly, not sure about that last one).
Regards,
Hans
On Tue, 21 Mar 2017, at 02:26 PM, Hans de Goede wrote:
Hi,
On 21-03-17 08:54, Arun Raghavan wrote:
On Tue, 21 Mar 2017, at 11:10 AM, Takashi Iwai wrote:
On Tue, 21 Mar 2017 00:09:22 +0100, Pierre-Louis Bossart wrote:
On 3/20/17 4:52 AM, Takashi Iwai wrote:
On Mon, 20 Mar 2017 12:42:58 +0100, Hans de Goede wrote:
Hi,
Lately I've been working on fixing various issues people are having with baytrail / cherrytrail devices. One thing I noticed when moving my testing / development to 4.11 is that pulseaudio does not work (it aborts while starting) this seemed to be caused by the new snd_hdmi_lpe_audio module. If I blacklist that all is fine. Any idea what is causing this ?
I noticed it once, too, but I had no time to check further. More interestingly, PA works fine when LPE audio is the single driver (i.e. blacklist Intel SST instead), too. So it's more likely a bug in PA.
What happens when you modprobe LPE audio driver after starting the session? If it kills PA, we can debug more easily :)
I've seen this as well, I could get either one of the two but not both, could this be due to the fact that one set of mixers is configured with UCM and the other driver isn't configured by UCM?
No idea, and I had still no time to check (still processing the pile of pending mails and other bugs :). Let me add PA guys to Cc.
Not sure if anyone here has the hardware and I haven't seen any complaints either -- having a backtrace (or even location of the assert) would be a good start.
Ok, this is weird. Since you were asking for more info I tried to collect a backtrace / logs. But what is happening is that after the snd_hdmi_lpe_audio module loads, pulse does its thing and then exits with a message of "killed" in gdb / on the terminal from which I started it. I don't get a chance to get a backtrace in gdb ... So this does feel like a kernel bug to me, normally this sort of "killed" behavior is seen on some kernel oopses...
But dmesg is free of any oopses ?
Anyways here is a log of pulseaudio -v first without the hdmi module and then the module gets probed. Where the log abruptly ends is where I got the "Killed" message on the terminal.
That's the kernel killing of PA for exceeding RT limits (there's a patch in the timers tip that'll now provide an error in dmesg).
It sounds possible that there is some call to the ALSA API that we are making that results in the driver blocking for long enough to exceed the RT limit. You can verify this by setting 'realtime-scheduling = no' in /etc/pulse/daemon.conf and then starting PA.
If that works, perf will likely be able to show you what's blocking.
-- Arun
Hi,
On 21-03-17 10:04, Arun Raghavan wrote:
On Tue, 21 Mar 2017, at 02:26 PM, Hans de Goede wrote:
Hi,
On 21-03-17 08:54, Arun Raghavan wrote:
On Tue, 21 Mar 2017, at 11:10 AM, Takashi Iwai wrote:
On Tue, 21 Mar 2017 00:09:22 +0100, Pierre-Louis Bossart wrote:
On 3/20/17 4:52 AM, Takashi Iwai wrote:
On Mon, 20 Mar 2017 12:42:58 +0100, Hans de Goede wrote: > > Hi, > > Lately I've been working on fixing various issues people > are having with baytrail / cherrytrail devices. One thing > I noticed when moving my testing / development to 4.11 is > that pulseaudio does not work (it aborts while starting) > this seemed to be caused by the new snd_hdmi_lpe_audio > module. If I blacklist that all is fine. Any idea what > is causing this ?
I noticed it once, too, but I had no time to check further. More interestingly, PA works fine when LPE audio is the single driver (i.e. blacklist Intel SST instead), too. So it's more likely a bug in PA.
What happens when you modprobe LPE audio driver after starting the session? If it kills PA, we can debug more easily :)
I've seen this as well, I could get either one of the two but not both, could this be due to the fact that one set of mixers is configured with UCM and the other driver isn't configured by UCM?
No idea, and I had still no time to check (still processing the pile of pending mails and other bugs :). Let me add PA guys to Cc.
Not sure if anyone here has the hardware and I haven't seen any complaints either -- having a backtrace (or even location of the assert) would be a good start.
Ok, this is weird. Since you were asking for more info I tried to collect a backtrace / logs. But what is happening is that after the snd_hdmi_lpe_audio module loads, pulse does its thing and then exits with a message of "killed" in gdb / on the terminal from which I started it. I don't get a chance to get a backtrace in gdb ... So this does feel like a kernel bug to me, normally this sort of "killed" behavior is seen on some kernel oopses...
But dmesg is free of any oopses ?
Anyways here is a log of pulseaudio -v first without the hdmi module and then the module gets probed. Where the log abruptly ends is where I got the "Killed" message on the terminal.
That's the kernel killing of PA for exceeding RT limits (there's a patch in the timers tip that'll now provide an error in dmesg).
It sounds possible that there is some call to the ALSA API that we are making that results in the driver blocking for long enough to exceed the RT limit. You can verify this by setting 'realtime-scheduling = no' in /etc/pulse/daemon.conf and then starting PA.
If that works,
Yep that works, good call.
perf will likely be able to show you what's blocking.
I'm not all that familiar with perf, can you provide me with a perf cmdline to start pulseaudio with which will generate a log file with the info you are looking for ?
Regards,
Hans
On Tue, 21 Mar 2017, at 08:19 PM, Hans de Goede wrote:
Hi,
On 21-03-17 10:04, Arun Raghavan wrote:
On Tue, 21 Mar 2017, at 02:26 PM, Hans de Goede wrote:
Hi,
On 21-03-17 08:54, Arun Raghavan wrote:
On Tue, 21 Mar 2017, at 11:10 AM, Takashi Iwai wrote:
On Tue, 21 Mar 2017 00:09:22 +0100, Pierre-Louis Bossart wrote:
On 3/20/17 4:52 AM, Takashi Iwai wrote: > On Mon, 20 Mar 2017 12:42:58 +0100, > Hans de Goede wrote: >> >> Hi, >> >> Lately I've been working on fixing various issues people >> are having with baytrail / cherrytrail devices. One thing >> I noticed when moving my testing / development to 4.11 is >> that pulseaudio does not work (it aborts while starting) >> this seemed to be caused by the new snd_hdmi_lpe_audio >> module. If I blacklist that all is fine. Any idea what >> is causing this ? > > I noticed it once, too, but I had no time to check further. > More interestingly, PA works fine when LPE audio is the single driver > (i.e. blacklist Intel SST instead), too. So it's more likely a bug in > PA. > > What happens when you modprobe LPE audio driver after starting the > session? If it kills PA, we can debug more easily :)
I've seen this as well, I could get either one of the two but not both, could this be due to the fact that one set of mixers is configured with UCM and the other driver isn't configured by UCM?
No idea, and I had still no time to check (still processing the pile of pending mails and other bugs :). Let me add PA guys to Cc.
Not sure if anyone here has the hardware and I haven't seen any complaints either -- having a backtrace (or even location of the assert) would be a good start.
Ok, this is weird. Since you were asking for more info I tried to collect a backtrace / logs. But what is happening is that after the snd_hdmi_lpe_audio module loads, pulse does its thing and then exits with a message of "killed" in gdb / on the terminal from which I started it. I don't get a chance to get a backtrace in gdb ... So this does feel like a kernel bug to me, normally this sort of "killed" behavior is seen on some kernel oopses...
But dmesg is free of any oopses ?
Anyways here is a log of pulseaudio -v first without the hdmi module and then the module gets probed. Where the log abruptly ends is where I got the "Killed" message on the terminal.
That's the kernel killing of PA for exceeding RT limits (there's a patch in the timers tip that'll now provide an error in dmesg).
It sounds possible that there is some call to the ALSA API that we are making that results in the driver blocking for long enough to exceed the RT limit. You can verify this by setting 'realtime-scheduling = no' in /etc/pulse/daemon.conf and then starting PA.
If that works,
Yep that works, good call.
perf will likely be able to show you what's blocking.
I'm not all that familiar with perf, can you provide me with a perf cmdline to start pulseaudio with which will generate a log file with the info you are looking for ?
I'm no perf expert myself, but I'd start with:
1. sudo perf sched record 2. Start PA in another tab 3. sudo perf sched latency > latency.txt
The latency report should show you at what time the maximum delay occurred and how large it was.
Thinking about it, a simple 'perf record pulseaudio' and 'perf report' might also tell you where CPU time was spent.
Cheers, Arun
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?
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?
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.
Takashi
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?
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
On Fri, 2017-03-24 at 23:01 +0100, Hans de Goede wrote:
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 ?
The perf output would be interesting.
It's still unclear to me if the hwsync thing is a bug in alsa, or something that pulseaudio should deal with. If there's no further input from the alsa developers, would you be able to test a pulseaudio patch if I write one? First I'd like to check whether the hwsync error happens inside snd_pcm_start(), and if so, does the error get reported in the snd_pcm_start() return value. If snd_pcm_start() returns an error, pulseaudio should probably react to it, although I'm not sure how. It would be easy to just remove the sink if there's an error, but I understood Takashi's comment so that it might be an intermittent error that depends on the graphics state, and if that's the case, pulseaudio would have to retry when the graphics state changes, but I don't know what kind of event could be used to get a notification about the state change.
On Tue, 28 Mar 2017 22:10:28 +0200, Tanu Kaskinen wrote:
On Fri, 2017-03-24 at 23:01 +0100, Hans de Goede wrote:
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 ?
The perf output would be interesting.
It's still unclear to me if the hwsync thing is a bug in alsa, or something that pulseaudio should deal with. If there's no further input from the alsa developers, would you be able to test a pulseaudio patch if I write one? First I'd like to check whether the hwsync error happens inside snd_pcm_start(), and if so, does the error get reported in the snd_pcm_start() return value. If snd_pcm_start() returns an error, pulseaudio should probably react to it, although I'm not sure how. It would be easy to just remove the sink if there's an error, but I understood Takashi's comment so that it might be an intermittent error that depends on the graphics state, and if that's the case, pulseaudio would have to retry when the graphics state changes, but I don't know what kind of event could be used to get a notification about the state change.
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?
thanks,
Takashi
On Wed, 2017-03-29 at 07:21 +0200, Takashi Iwai wrote:
On Tue, 28 Mar 2017 22:10:28 +0200, Tanu Kaskinen wrote:
On Fri, 2017-03-24 at 23:01 +0100, Hans de Goede wrote:
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 ?
The perf output would be interesting.
It's still unclear to me if the hwsync thing is a bug in alsa, or something that pulseaudio should deal with. If there's no further input from the alsa developers, would you be able to test a pulseaudio patch if I write one? First I'd like to check whether the hwsync error happens inside snd_pcm_start(), and if so, does the error get reported in the snd_pcm_start() return value. If snd_pcm_start() returns an error, pulseaudio should probably react to it, although I'm not sure how. It would be easy to just remove the sink if there's an error, but I understood Takashi's comment so that it might be an intermittent error that depends on the graphics state, and if that's the case, pulseaudio would have to retry when the graphics state changes, but I don't know what kind of event could be used to get a notification about the state change.
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?
On Wed, 29 Mar 2017 14:59:45 +0200, Tanu Kaskinen wrote:
On Wed, 2017-03-29 at 07:21 +0200, Takashi Iwai wrote:
On Tue, 28 Mar 2017 22:10:28 +0200, Tanu Kaskinen wrote:
On Fri, 2017-03-24 at 23:01 +0100, Hans de Goede wrote:
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 ?
The perf output would be interesting.
It's still unclear to me if the hwsync thing is a bug in alsa, or something that pulseaudio should deal with. If there's no further input from the alsa developers, would you be able to test a pulseaudio patch if I write one? First I'd like to check whether the hwsync error happens inside snd_pcm_start(), and if so, does the error get reported in the snd_pcm_start() return value. If snd_pcm_start() returns an error, pulseaudio should probably react to it, although I'm not sure how. It would be easy to just remove the sink if there's an error, but I understood Takashi's comment so that it might be an intermittent error that depends on the graphics state, and if that's the case, pulseaudio would have to retry when the graphics state changes, but I don't know what kind of event could be used to get a notification about the state change.
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?
thanks,
Takashi
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:
On Tue, 28 Mar 2017 22:10:28 +0200, Tanu Kaskinen wrote:
On Fri, 2017-03-24 at 23:01 +0100, Hans de Goede wrote:
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 ?
The perf output would be interesting.
It's still unclear to me if the hwsync thing is a bug in alsa, or something that pulseaudio should deal with. If there's no further input from the alsa developers, would you be able to test a pulseaudio patch if I write one? First I'd like to check whether the hwsync error happens inside snd_pcm_start(), and if so, does the error get reported in the snd_pcm_start() return value. If snd_pcm_start() returns an error, pulseaudio should probably react to it, although I'm not sure how. It would be easy to just remove the sink if there's an error, but I understood Takashi's comment so that it might be an intermittent error that depends on the graphics state, and if that's the case, pulseaudio would have to retry when the graphics state changes, but I don't know what kind of event could be used to get a notification about the state change.
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.
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).
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:
On Tue, 28 Mar 2017 22:10:28 +0200, Tanu Kaskinen wrote:
On Fri, 2017-03-24 at 23:01 +0100, Hans de Goede wrote:
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 ?
The perf output would be interesting.
It's still unclear to me if the hwsync thing is a bug in alsa, or something that pulseaudio should deal with. If there's no further input from the alsa developers, would you be able to test a pulseaudio patch if I write one? First I'd like to check whether the hwsync error happens inside snd_pcm_start(), and if so, does the error get reported in the snd_pcm_start() return value. If snd_pcm_start() returns an error, pulseaudio should probably react to it, although I'm not sure how. It would be easy to just remove the sink if there's an error, but I understood Takashi's comment so that it might be an intermittent error that depends on the graphics state, and if that's the case, pulseaudio would have to retry when the graphics state changes, but I don't know what kind of event could be used to get a notification about the state change.
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.
Takashi
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?
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.
Takashi
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.
I created a bug report here: https://bugs.freedesktop.org/show_bug.cgi?id=100488
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
On Wed, 2017-03-29 at 16:14 +0300, 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.
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).
Adding to that: ignoring hw:1,0 won't be enough. For jack detection, pulseaudio will look for a jack control named HDMI/DP,pcm=3, which probably won't exist if HDMI uses hw:1,0.
On Wed, 29 Mar 2017 15:27:17 +0200, Tanu Kaskinen wrote:
On Wed, 2017-03-29 at 16:14 +0300, 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.
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).
Adding to that: ignoring hw:1,0 won't be enough. For jack detection, pulseaudio will look for a jack control named HDMI/DP,pcm=3, which probably won't exist if HDMI uses hw:1,0.
For LPE audio, it's "HDMI/DP" (with ",pcm=*" that can be omitted for dev=0).
Takashi
participants (5)
-
Arun Raghavan -
Hans de Goede -
Pierre-Louis Bossart -
Takashi Iwai -
Tanu Kaskinen