On 02/13/2017 08:39 AM, Takashi Iwai wrote:
Hi,
Linus decided to take another week for 4.11 merge window, so I could play a bit more, and here is the result :)
The first patch is the fix for possible GPU hang, and this has been for a while in my local branch and tested. This should be OK to merge soon. (It's also as same as what Ian tested in the last weekend.)
The next one is merely a cleanup patch, so it's fine, too. The third one is a transition to use the runtime PM autosuspend, and it's a preliminary for the last change.
The last one is the new and experimental one: it enables the keep-link feature. With this patch, the device is managed as default via autosuspend, and the link is opened (but silenced) for the pre-given time (2 seconds) after the PCM close. If the application restarts the stream quickly, the receiver is still warm and can resume gracefully.
All these patches are found in topic/intel-lpe-audio branch. (BTW, I cleaned up my branches: now for-next branch tracks the latest stable patches to be merged, while topic/intel-lpe-audio branch tracks the experimental patches. Beware that the latter may be rebased frequently.)
I tried this topic/intel-lpe-audio branch on my Baytrail compute stick and CHT boards and I see a couple of problems while monkey testing.
1. PulseAudio fails to load the HDMI card on startup on the Compute Stick and only shows the dummy output, killing and restarting PulseAudio solves the problem. I had not seen this before and this doesn't happen on CHT devices, not sure if this a pulseaudio problem?
2. we had a set of errors in the past that are still present, i see them 100% of the time: E: [alsa-sink-HdmiLpeAudio] alsa-sink.c: ALSA woke us up to write new data to the device, but there was a ctually nothing to write! E: [alsa-sink-HdmiLpeAudio] alsa-sink.c: Most likely this is a bug in the ALSA driver 'snd_hdmi_lpe_audio '. Please report this issue to the ALSA developers. E: [alsa-sink-HdmiLpeAudio] alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent snd_pc m_avail() returned 0 or another value < min_avail.
3. the third one is new, we have something wrong with the pointer management. This happened only once in my tests but still, not sure how it was introduced.
E: [alsa-sink-HdmiLpeAudio] alsa-util.c: snd_pcm_avail() returned a value that is exceptionally large: 13 6128 bytes (709 ms). E: [alsa-sink-HdmiLpeAudio] alsa-util.c: Most likely this is a bug in the ALSA driver 'snd_hdmi_lpe_audio '. Please report this issue to the ALSA developers. E: [alsa-sink-HdmiLpeAudio] alsa-util.c: snd_pcm_dump(): E: [alsa-sink-HdmiLpeAudio] alsa-util.c: Hardware PCM card 0 'Intel HDMI/DP LPE Audio' device 0 subdevice 0 E: [alsa-sink-HdmiLpeAudio] alsa-util.c: Its setup is: E: [alsa-sink-HdmiLpeAudio] alsa-util.c: stream : PLAYBACK E: [alsa-sink-HdmiLpeAudio] alsa-util.c: access : MMAP_INTERLEAVED E: [alsa-sink-HdmiLpeAudio] alsa-util.c: format : S16_LE E: [alsa-sink-HdmiLpeAudio] alsa-util.c: subformat : STD E: [alsa-sink-HdmiLpeAudio] alsa-util.c: channels : 2 E: [alsa-sink-HdmiLpeAudio] alsa-util.c: rate : 48000 E: [alsa-sink-HdmiLpeAudio] alsa-util.c: exact rate : 48000 (48000/1) E: [alsa-sink-HdmiLpeAudio] alsa-util.c: msbits : 16 E: [alsa-sink-HdmiLpeAudio] alsa-util.c: buffer_size : 3840 E: [alsa-sink-HdmiLpeAudio] alsa-util.c: period_size : 480 E: [alsa-sink-HdmiLpeAudio] alsa-util.c: period_time : 10000 E: [alsa-sink-HdmiLpeAudio] alsa-util.c: tstamp_mode : ENABLE E: [alsa-sink-HdmiLpeAudio] alsa-util.c: period_step : 1 E: [alsa-sink-HdmiLpeAudio] alsa-util.c: avail_min : 480 E: [alsa-sink-HdmiLpeAudio] alsa-util.c: period_event : 1 E: [alsa-sink-HdmiLpeAudio] alsa-util.c: start_threshold : -1 E: [alsa-sink-HdmiLpeAudio] alsa-util.c: stop_threshold : 8646911284551352320 E: [alsa-sink-HdmiLpeAudio] alsa-util.c: silence_threshold: 0 E: [alsa-sink-HdmiLpeAudio] alsa-util.c: silence_size : 0 E: [alsa-sink-HdmiLpeAudio] alsa-util.c: boundary : 8646911284551352320 E: [alsa-sink-HdmiLpeAudio] alsa-util.c: appl_ptr : 301456 E: [alsa-sink-HdmiLpeAudio] alsa-util.c: hw_ptr : 331680
Indeed this looks like a wrap-around?
4. the keep-link thing doesn't seem to work for me. Once PulseAudio suspends the output, if I try to play a short notification I lose the first second (as in hearing only 'left' in 'front left', as in with the first sound I play. I even increased the threshold to 10s and still no joy. Could there be a higher level suspend that turns the link off?
5. if I change the display resolution while playing a sound through hw:0, at the ALSA level the playback stops with all sorts of bad descriptor errors, which is fine. If I play through PulseAudio the card is unloaded when the resolution is changed and the sound keeps playing but to the dummy output. PulseAudio needs to be killed and restarted to play sound again over HDMI. Wondering if this is the same problem as for the first case, PulseAudio not able to digest a uevent when a card is created?
6. if I remove the HDMI output and reinsert it, PulseAudio again fails to detect. I have to kill pulseaudio and restart it. I also saw this log during plug/unplug W: [alsa-sink-HdmiLpeAudio] alsa-util.c: Could not recover from POLLERR|POLLNVAL|POLLHUP with snd_pcm_pre pare(): No such device
7. I can't get the multichannel sound to work, anything with more that 2ch is silent except for FR and FL. Playback keeps going but only 2 channels are playing. Not sure if this is my receiver sending bad ELD information or just that the hw_params are not limited to the capabilities of the display.
Overall it's pretty robust though compared to the legacy patches, except for the pulseaudio detection issue there was never a moment where I had to reboot or do something drastic to recover. Thanks for all your work Takashi!