pulseaudio fails to start with kernel 4.11, caused by new snd_hdmi_lpe_audio module)

pulseaudio fails to start with kernel 4.11, caused by new snd_hdmi_lpe_audio module)

[Hans de Goede]

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

Re: pulseaudio fails to start with kernel 4.11, caused by new snd_hdmi_lpe_audio module)

[Takashi Iwai]

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

Re: pulseaudio fails to start with kernel 4.11, caused by new snd_hdmi_lpe_audio module)

[Pierre-Louis Bossart]

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?

Re: pulseaudio fails to start with kernel 4.11, caused by new snd_hdmi_lpe_audio module)

[Takashi Iwai]

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
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: pulseaudio fails to start with kernel 4.11, caused by new snd_hdmi_lpe_audio module)

[Arun Raghavan]

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
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] pulseaudio fails to start with kernel 4.11, caused by new snd_hdmi_lpe_audio module)

[Hans de Goede]

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

Re: pulseaudio fails to start with kernel 4.11, caused by new snd_hdmi_lpe_audio module)

[Arun Raghavan]

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
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] pulseaudio fails to start with kernel 4.11, caused by new snd_hdmi_lpe_audio module)

[Hans de Goede]

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

Re: pulseaudio fails to start with kernel 4.11, caused by new snd_hdmi_lpe_audio module)

[Arun Raghavan]

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
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [alsa-devel] pulseaudio fails to start with kernel 4.11, caused by new snd_hdmi_lpe_audio module)

[Pierre-Louis Bossart]

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?
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] pulseaudio fails to start with kernel 4.11, caused by new snd_hdmi_lpe_audio module)

[Takashi Iwai]

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

Re: [alsa-devel] pulseaudio fails to start with kernel 4.11, caused by new snd_hdmi_lpe_audio module)

[Tanu Kaskinen]

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?

-- 
Tanu

https://www.patreon.com/tanuk
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] pulseaudio fails to start with kernel 4.11, caused by new snd_hdmi_lpe_audio module)

[Hans de Goede]

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

Re: [alsa-devel] pulseaudio fails to start with kernel 4.11, caused by new snd_hdmi_lpe_audio module)

[Tanu Kaskinen]

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.

-- 
Tanu

https://www.patreon.com/tanuk
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [alsa-devel] pulseaudio fails to start with kernel 4.11, caused by new snd_hdmi_lpe_audio module)

[Takashi Iwai]

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
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [alsa-devel] pulseaudio fails to start with kernel 4.11, caused by new snd_hdmi_lpe_audio module)

[Tanu Kaskinen]

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?

-- 
Tanu

https://www.patreon.com/tanuk
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [alsa-devel] pulseaudio fails to start with kernel 4.11, caused by new snd_hdmi_lpe_audio module)

[Takashi Iwai]

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
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] pulseaudio fails to start with kernel 4.11, caused by new snd_hdmi_lpe_audio module)

[Tanu Kaskinen]

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).

-- 
Tanu

https://www.patreon.com/tanuk

Re: [pulseaudio-discuss] pulseaudio fails to start with kernel 4.11, caused by new snd_hdmi_lpe_audio module)

[Takashi Iwai]

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

Re: [alsa-devel] pulseaudio fails to start with kernel 4.11, caused by new snd_hdmi_lpe_audio module)

[Tanu Kaskinen]

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.

-- 
Tanu

https://www.patreon.com/tanuk
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] pulseaudio fails to start with kernel 4.11, caused by new snd_hdmi_lpe_audio module)

[Takashi Iwai]

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

Re: [alsa-devel] pulseaudio fails to start with kernel 4.11, caused by new snd_hdmi_lpe_audio module)

[Tanu Kaskinen]

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?

-- 
Tanu

https://www.patreon.com/tanuk
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [alsa-devel] pulseaudio fails to start with kernel 4.11, caused by new snd_hdmi_lpe_audio module)

[Takashi Iwai]

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
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [alsa-devel] pulseaudio fails to start with kernel 4.11, caused by new snd_hdmi_lpe_audio module)

[Tanu Kaskinen]

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

-- 
Tanu

https://www.patreon.com/tanuk
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [alsa-devel] pulseaudio fails to start with kernel 4.11, caused by new snd_hdmi_lpe_audio module)

[Takashi Iwai]

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
> 
> https://www.patreon.com/tanuk
> 
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss