B50 /BP50 Firmware Version Update 0057-5be7aedf

[trinitronx]

@zpl1025

1. When device go in standby, it will only monitor the IO changes to wake up. So, the ARC could wake it, because it’s monitoring the CEC line and wake up to handle CEC messages. For Line-In, I’m not sure we could do this. Maybe could wake up periodically to read the ADC and determine whether audio input is available. I’m not sure if this is a good idea, maybe others just want it to stay in standby.

After a few months of testing this, I can confirm that when CEC messages are working properly, the BP50 will wake up and sleep correctly. I’m sure there are a few edge cases where CEC messages stop working for some reason, but I’ve been unable to track down exactly why or when this happens. Usually a reboot of the PC will solve the issue when the CEC adapter software says it is not responding.

For my test setup:

I have an HTPC running Linux with a Pulse-Eight USB to CEC Adapter (device ID 2548:1002). I’ve modified the source code for a software called cec-dpms to always send the power off command to the TV, even when the “Playbackdevice1” is not currently “active source”. Previously, the software was coded to only send if the “Playback Device 1” (in CEC logical address parlance ), is still seen as “active source”, but I found that for my TV and HTPC, the original boolean if statement was always false. So, before that change the device would never go into standby properly when HTPC was idle unless the TV itself was powered off manually. I think my TV sends a power off CEC command to the BP50, but somehow fails to send the power on command when the TV is turned back on. So, I needed to set up my HTPC to turn on the BP50 with some software and that CEC adapter.

I set up a SystemD unit to automatically run via udev which automatically attaches an instance of the cec-dpms service to /dev/ttyACM0 (or any other Pulse-Eight CEC adapter device) when it first shows up to the Linux kernel. So, in my case when /dev/ttyACM0 is identified by udev, it starts cec-dpms@dev-ttyACM0.service. Then, I hooked the USR1 and USR2 cec-dpms process signals up into my desktop’s idle handler. In my case, that was swayidle. If you’re curious, the config I used is below.

Sway Lock/Idle config

# Set long options in config file: ~/.config/swaylock/config
# Otherwise, we get segfault from swayidle PID
set $locking swaylock --daemonize

### Idle configuration
# This will lock your screen after 300 seconds of inactivity, then turn off
# your displays after another 300 seconds, and turn your screens back on when
# resumed. It will also lock your screen before your computer goes to sleep.
#
set $idle_timeout 240
set $locking_timeout 300
set $screen_timeout 600
set $sleep_timeout 900
set $sleep_delay 2

# Shell no-op to turn off suspend
set $systemctl_suspend :

set $swayidle swayidle -w -S seat0 \
    idlehint $idle_timeout \
    timeout $idle_timeout 'light -G > /tmp/brightness && light -S 10' resume 'light -S $([ -f /tmp/brightness ] && cat /tmp/brightness || echo 100%)' \
    timeout $locking_timeout 'exec $locking' \
    timeout $screen_timeout 'swaymsg "output * power off"' \
      resume 'swaymsg "output * power on"' \
    timeout $screen_timeout 'sudo pkill -USR2 cec-dpms' \
      resume 'sudo pkill -USR1 cec-dpms' \
    before-sleep 'playerctl pause' \
    before-sleep 'exec $locking & sleep $sleep_delay'

@zpl1025

1. […SNIP…]. Maybe could wake up periodically to read the ADC and determine whether audio input is available. I’m not sure if this is a good idea, maybe others just want it to stay in standby.
2. This is actually having the same issue. Maybe user just want to keep the input, and he want to switch with his intention. If I’m watching TV, I for sure don’t want to be disturbed by such auto switch feature.

It might be good for some users to have the option to turn on some kind of HDMI ARC audio wake-up polling. This might have avoided the need for me to use the separate cec-dpms software.

As far as being disturbed by the auto-switch behavior, I’ve noticed that with my cec-dpms and swayidle setup, there are a few issues like this. It’s really my fault, in this case because I always send the set_active_source() CEC command when the HTPC wakes up from idle. Maybe I will find a way to determine if my particular TV is watching another source, and simply don’t send that CEC command.

1. When watching content on the TV itself (e.g. TV’s built-in Netflix “app”), if the HTPC mouse or keyboard is bumped or pressed then the PC will wake up from idle state and tell cec-dpms to send the power on and set_active_source(). So, in this case the TV will exit out of the Netflix app and display the HTPC’s video output instead. Oops!
2. Sometimes, the CEC adapter gets into a broken state where it fails to communicate with the TV. When this happens, I usually try restarting the cec-dpms service first, and when that usually fails to work, I have to reboot the HTPC. After a reboot, the CEC commands will succeed again.
3. Sometimes the BP50 will stop playing audio. I think this issue has been described by a few other people (e.g. this post, and also this post ) too. It may have something to do with the BP50 losing digital audio clock sync (maybe PLL “flywheel” has failed to keep sync and did not recover?). I’m not 100% sure about this, and don’t have equipment to capture and debug the HDMI ARC digital signal, so it’s just a guess. When the BP50 has entered this state, it will fail to play HDMI ARC audio until I switch back and forth from another input (e.g. Set input to Line In, then back to HDMI ARC ). I sometimes also have to switch the Vizio TV’s audio output from PCM to Bitstream and back, and/or turn the built-in TV speakers On and back Off again, which seems to somehow “reset” the digital audio signal sent over the HDMI ARC output port.