Rough edges and how I work around them (or not)

[Borley]

Apologies for bumping this, but has anyone figured out why this happens? I'm running into this constantly, and everything I've tried to avoid having to do a full power cycle has failed. I tried powering off the individual ports of the hub (the only Genesys Logic hub on the board, GL852 I believe) it is connected to, powering off the entire hub that it is connected to (not just individual ports), and even powering off the TI USB Hub that pretty much the entire system uses, but none of them bring the audio device back.

I have found that instead of rebooting, it is possible to just restart the pulseaudio service (for those of us using pulseaudio and systemd):

Code: [Select]

systemctl --user restart pulseaudio
Always corrects the issue within seconds. Maybe a script that runs this a minute or two after login would automate the problem away.

[Borley]

Can you please see if this is fixed by this update?

Please confirm the ffmpeg version you are using

I will tag this to check. I am currently on ffmpeg 4.1.6.

I'm so bad with consistency. Anyway, just checked with the same script while using ffmpeg 4.3.5. Problem persists.

Here is the script:

Code: [Select]

#!/bin/sh

if test $# -lt 6; then
        cat <<-EOH
        $0: Script to generate animated gifs easily from command line.
       
        Usage:
       
        $0 input.(mp4|avi|webm|flv|...) output.gif horizontal_resolution fps start_time duration
        EOH
    exit 1
fi

palette="$(mktemp /tmp/ffmpeg2gifXXXXXX.png)"

filters="fps=$4,scale=$3:-1:flags=lanczos"

ffmpeg -v warning -ss "$5" -t "$6" -i "$1" -vf "$filters,palettegen" -y "$palette"
ffmpeg -v warning -ss "$5" -t "$6" -i "$1" -i $palette -lavfi "$filters [x]; [x][1:v] paletteuse" -y "$2"

rm -f "$palette"

The file it produces, from a sample:

[Corvidae]

I have found that instead of rebooting, it is possible to just restart the pulseaudio service (for those of us using pulseaudio and systemd):

Code: [Select]

systemctl --user restart pulseaudio
Always corrects the issue within seconds. Maybe a script that runs this a minute or two after login would automate the problem away.

Are you saying your audio device doesn't drop off the USB bus completely? If I do a "hot reboot", i.e. OS -> Petitboot -> OS, the audio device is fine and works straight away. If I do a proper shutdown that turns off the CPU, status light turns orange, etc, then if I start the system again the audio device is completely gone from the USB subsystem until I completely remove all power from the system.

If it is working for you, I'd be curious to know what revision Blackbird board you have - I wonder if that makes a difference here (I have 1.02).

[Borley]

Are you saying your audio device doesn't drop off the USB bus completely? If I do a "hot reboot", i.e. OS -> Petitboot -> OS, the audio device is fine and works straight away. If I do a proper shutdown that turns off the CPU, status light turns orange, etc, then if I start the system again the audio device is completely gone from the USB subsystem until I completely remove all power from the system.

If it is working for you, I'd be curious to know what revision Blackbird board you have - I wonder if that makes a difference here (I have 1.02).

It is possible that our issues are just similar yet separate. What happens for me is that sometimes (a minority of bootups) GNOME will only report the existence of my HDMI audio through the GPU with no dropdown option for the usual "CM106 Like Sound Device" or it might just erroneously say "Speakers" (which provide no audio out when tested). Restarting pulseaudio appears to rectify this.

My main board is revision 1.01.

[Corvidae]

It is possible that our issues are just similar yet separate. What happens for me is that sometimes (a minority of bootups) GNOME will only report the existence of my HDMI audio through the GPU with no dropdown option for the usual "CM106 Like Sound Device" or it might just erroneously say "Speakers" (which provide no audio out when tested). Restarting pulseaudio appears to rectify this.

My main board is revision 1.01.

It sounds like that might be the case. The issue I am experiencing is that the audio device never even appears as a connected USB device, so it doesn't even have a chance to get to the audio system. As an example, here is the relevant output of lsusb -tv when I am booted into the host system with the audio device working (I plugged in a flash drive to the board USB port to rule out the hub being bad):

Code: [Select]

/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
    <...>
    |__ Port 4: Dev 5, If 0, Class=Hub, Driver=hub/4p, 480M
        ID 05e3:0610 Genesys Logic, Inc. Hub
        |__ Port 3: Dev 8, If 0, Class=Mass Storage, Driver=usb-storage, 480M
            ID 154b:007a PNY Classic Attache Flash Drive
        |__ Port 4: Dev 7, If 0, Class=Audio, Driver=snd-usb-audio, 12M
            ID 0d8c:0102 C-Media Electronics, Inc. CM106 Like Sound Device
        |__ Port 4: Dev 7, If 1, Class=Audio, Driver=snd-usb-audio, 12M
            ID 0d8c:0102 C-Media Electronics, Inc. CM106 Like Sound Device
        |__ Port 4: Dev 7, If 2, Class=Audio, Driver=snd-usb-audio, 12M
            ID 0d8c:0102 C-Media Electronics, Inc. CM106 Like Sound Device
        |__ Port 4: Dev 7, If 3, Class=Human Interface Device, Driver=usbhid, 12M
            ID 0d8c:0102 C-Media Electronics, Inc. CM106 Like Sound Device

But if I shut down the system with power still connected, then boot back into the host system, this is what I get:

Code: [Select]

/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
    <...>
    |__ Port 4: Dev 5, If 0, Class=Hub, Driver=hub/4p, 480M
        ID 05e3:0610 Genesys Logic, Inc. Hub
        |__ Port 3: Dev 7, If 0, Class=Mass Storage, Driver=usb-storage, 480M
            ID 154b:007a PNY Classic Attache Flash Drive

The flash drive I plugged into the lone USB port on the board is still present, so it's (probably) not the hub that is having issues.  Checking dmesg output also doesn't have any useful information beyond it just not saying anything relating to the audio device when it is not being detected. Other than the board revision, the only other major difference between our setups is that I'm using pipewire instead of pulseaudio, but given that the USB device is not there in the first place I doubt that is the issue here.

[Borley]

Now that you describe it, yes my system does the same thing. I've just trained myself into always fully powering off the system whenever I reboot. So I haven't had to deal with the issue since that is now normal operating procedure for me. So no, nothing is wrong with your particular board. I think all Blackbirds are affected.

If Raptor products ever do get support for suspend to RAM, this audio adapter disappearing is probably something that both development and users will run into. Here's a quick check against my kernel boot logs:

Code: [Select]

1 Time(s): usb 1-4.4: New USB device found, idVendor=0d8c, idProduct=0102, bcdDevice= 0.10
 1 Time(s): usb 1-4.4: New USB device strings: Mfr=0, Product=2, SerialNumber=0
 1 Time(s): usb 1-4.4: Product: USB Sound Device       
 3 Time(s): usb 1-4.4: Warning! Unlikely big volume range (=6928), cval->res is probably wrong.
 2 Time(s): usb 1-4.4: Warning! Unlikely big volume range (=8065), cval->res is probably wrong.
 1 Time(s): usb 1-4.4: [11] FU [Line Playback Volume] ch = 2, val = -6144/1921/1
 1 Time(s): usb 1-4.4: [15] FU [Line Capture Volume] ch = 2, val = -4096/2832/1
 1 Time(s): usb 1-4.4: [2] FU [PCM Capture Volume] ch = 2, val = -4096/2832/1
 1 Time(s): usb 1-4.4: [8] FU [Mic Capture Volume] ch = 2, val = -4096/2832/1
 1 Time(s): usb 1-4.4: [9] FU [Mic Playback Volume] ch = 2, val = -6144/1921/1
 1 Time(s): usb 1-4.4: current rate 30464 is different from the runtime rate 96000
 1 Time(s): usb 1-4.4: new full-speed USB device number 7 using xhci_hcd
If you reboot (remaining on mains power), I wonder what, or if any, output for this device is.

[Corvidae]

My logs when rebooting straight to Petitboot are pretty much the same as when freshly booting after reconnecting power (both cases the audio device works), and I get no related log output at all when booting from shutdown with power still connected (where the audio device is gone). As an experiment, I tried resetting power on the USB port the audio device is on when it is already working, and it came back and worked again as normal. The issue doesn't seem to be as simple as it breaking when losing power. If anyone wants to experiment themselves, I found that the "uhubctl" program worked well for me. Just make sure to carefully read the help output and select the right port(s), as otherwise you might cut power to all USB devices and lose keyboard input.

[Borley]

Debian Bookworm ffmpeg 5.1.4-0+deb12u1 introduces an issue where default h264 encoding for mp4 videos creates artifacting. Green patches on frame-by-frame changes.

It can be worked around by manually specifying a different video codec.

Code: [Select]

ffmpeg -i sample.mp4 -vcodec mpeg2video output.mp4

[Hasturtium]

It seems like video encoding on Power9 has been a rough edge on the platform since the beginning... I know the VP9 encoder was getting some decent ppc64le optimizations several years back; did those ever get merged into trunk? Short of using a hardware-assisted encoder I don't even know what my options are that don't require encoding to 480p.