Bug (solved): OMXPlayer on Stretch-based builds stutters on composite

matchaman

Yes, this is definitely my problem. Could these threads be merged?

@pjft Yes, everything slows down at a very "stable" slow motion. It's almost like a joke :p

Edit: merged, thanks :)

matchaman

@mitu I don't understand how can I see the parameters of something that happens within the ES GUI. After I let the bug "happen", should I exit to the shell and use a particular command to see what was previously used within ES?

@pjft Indeed I suspect a driver issue that causes everything to slow down to about 50%. I actually used a metronome for familiar music that slowed down!

What's really messing with my sanity is that the slowdown is somewhat uniform and universal across anything that runs after it occurs. Every emulator, video and audio runs at the aforementioned speed. Even typing seems to have the exact slowdown!

My logic agrees with your speculation, it's most like a driver thing that's triggered by the combination of ES and omxplayer, since the exact same versions work fine with the Jessie kernel.

mitu

@matchaman (topics merged). You use htop or ps -ef from a SSH session to see how omxplayer is started by Emulationstation, during the stuttering videos playing.

matchaman

I think I smell a rat in the params! Finally we're getting somewhere... :)

omxplayer --layer 10010 --loop --no-osd --aspect-mode stretch --vol -1000000 -o both --win 447,57,635,241 /home/pi/RetroPie/roms/videotest.mp4

First time I see the slowdown begin outside ES! I'll experiment to see which parameter causes the slowdown.

--win is adjusted by the theme, removing it didn't change anything

--vol -1000000 is for keeping the videos silent, set by ES, no change

--aspect-mode stretch, no change

... anything else, no change...

Aaaaaaaaaaaaaaaand... the devil is:

-o both

Oh my days... what is that and why does it cause the system-wide slowdown?

Edit:

-o --adev device Audio out device : e.g. hdmi/local/both/als

Things are pretty clear now: Stretch's driver for some reason does not accept this parameter because it's forcing audio devices to both (HDMI and analogue?). This is the problem for sure.

Can I set ES to stop using this parameter? I don't even think it's necessary from what I see, as audio output is set automatically in any case.

pjft

@matchaman You can change the OMX audio device in the ES settings. Try it.

Also, I would not start stating that the white noise is in any way related to this, at least for the time being. Nowhere did the other thread mention anything about video playback.

It may be related, but I'd be careful in jumping the gun.

matchaman

@pjft This is it! What a relief...

I changed the omxplayer audio device to ALSA:HW:0,0 and videos play smoothly. The problem is eliminated! ALSA:HW:1,0 makes videos not work at all. I guess 1,0 is for other hardware?

Since -o both causes such trouble, I think that it should either not be default or fixed for Stretch.

I am currently experimenting with HDMI and headphones and see if the problem can be replicated with both. I suggested that it's a problem of the same nature because slowdown-aside, there's white noise audible from my CRT TV's speakers.

pjft

@matchaman I don't know whether the default should be changed, as I suspect removing that will prevent it from running over HDMI, but if others with plain HDMI output cares to test and confirm that, it's an easy change!

Thanks, glad it's sorted there.

matchaman

You are welcome! I'm not entirely sure that it's solved because there will be more users getting stuck with this strange issue with default omxplayer audio (both).

ALSA:HW:0,0 seems to give the exact same result with what both did on Jessie builds. Audio on videos works seamlessly on HDMI and analogue boot ups.

mitu

@matchaman If you have a Github account, you should report the issue on the omxplayer's project page (https://github.com/popcornmix/omxplayer/issues), while searching for similar issues to this topic, I haven't encountered similar reports - most likely due to the fact that the switch to 4.14 kernel in Raspbian happened recently.

matchaman

@mitu I just did that :) I hope it's solved because more and more people using 240p via composite will encounter this soon.

Who would ever believe that a simple audio device switch would cause a system-wide slowdown and only on analogue A/V...

matchaman

Update: Oh dear... ALSA:HW:0,0 fixed it BUT causes some slight input lag within the menus. I initially thought it's my imagination or due to the large amount of videos and art. Then I played around and used localinstead of ALSA:HW:0,0and the (slight) delay was gone!

However, that made videos stay silent in HDMI so it's not a real fix. Later today I'll make a new fully updated Jessie build again and check performance between both, local and ALSA:HW:0,0.

The saga continues...

pjft

@matchaman ...but did local solve your specific problem though? You're running things via composite, so why is local not a solution to your specific issue? Was it more about whether to change the default option?

matchaman

I'm using a CRT TV in my office room above my PC monitor and when I game in the living room I connect it via HDMI, so I keep swapping composite and HDMI.

For now I'll probably keep switching between local and HDMI but both had been very convenient until Stretch and the afore issues.

The main problem is that I mostly use ES Kiosk mode because friends and relatives sometimes mess up my collections. Right now I'm between ALSA (and those slight hiccups) and manual switching each time.

pjft

@matchaman Got it.

Definitely keen on seeing how it goes over at the omxplayer issue tracker.

ohmycommodore

@matchaman Just encountered this issue and posted here (https://retropie.org.uk/forum/topic/20350/slow-scratchy-video-previews-on-crt-but-not-hdmi/4). Will be looking into this tonight. After reading, I'm not sure if you did get things working on both composite and HDMI. That's what I'm after as well, and thus I noticed the composite-only stuttering / slowdown issue.

ohmycommodore

@matchaman So is audio_pwm_mode=0 the complete solution? Or is there another step related to tweaking OMX player?

SinisterSpatula

My apologies for bringing this topic from the dead, but I'm definitely still having this problem and it's not really solved, just workaround solutions, and this is the most relevant place to ask about it. Also, I'm not using composite video and still see the issue. I'm seeing it on pi zero which has the same audio chip. The workarounds mentioned here do work for fixing it for me, when using emulationstation. I thought it must be a bug in ES, or in OMX player, but today I saw something that makes me think it's actually a raspbian issue. I was trying out Pegasus front end, and tried enabling hardware video acceleration by installing gstreamer1.0-omx and the exact same slow/stuttering/problematic video occurs. If I uninstall gstreamer1.0-omx and use software rendering for the same video, the issue goes away. I'm on a Pi zero. I have no idea how to switch the audio output away from "both hdmi and analog" when using gstreamer. It's been a problem on 4.4 and still on the latest 4.5.1 (which is what I'm using, stock 4.5.1 happens both with ES/omxplayer and Pegasus/gstreamer). I'm really puzzled why I can't find anyone else asking about this, probably because the workaround works for 99.99% of people who are using OMX player and ES. Any idea's how to achieve the same workaround for gstreamer1.0-omx ? (switching audio output device to Alsa HW 0,0 and having gstreamer avoid sending audio to both hdmi and analog?)

pjft

@SinisterSpatula interesting. I should have recalled this thread when I was running things on composite a few weeks ago but alas I didn't!

It is indeed a Raspbian/OMX... quirk, let's call it?

What worked for me was adding in

audio_pwm_mode=0

to config.txt , which was also the suggestion here:

https://retropie.org.uk/forum/topic/17864/raspberry-pi-ridiculously-slow-when-splashscreen-service-is-enabled/

See if it makes a difference.

SinisterSpatula

@pjft thanks for the reply! Well, I just tried pwm_audio_mode=0, 1, and 2. For 0 and 2 they were both equally bad. I tried 1 also just to see, and it was slightly better than 0 and 2 but still slow/not real-time. I'm also seeing this error on the console ALSA lib pcm.c:8306:(snd_pcm_recover) underrun occurred repeatedly, during the test play.

pjft

Sorry, I don't have a lot more ideas here, apologies. Does running standalone omx player result in the same stuttering?