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

[matchaman]

I came back from a friend who bought a 3 B+ model. He uses a brand new 4.3.17 test image, nothing added other than ROMs for systems. I asked him to scrape with videos for a system, switched to omxplayer in ES, used a jack to RCA cable and here we go... same problem!

I consider this a global issue :( someone who can use composite, PLEASE give me your input...

[matchaman]

Excuse me for "spam-bumping" this but it's a real issue that needs to be addressed.

I installed a clean image of 4.3 Jessie (on my 3 B model obviously) without any updates and the problem does not exist, as I expected.

I am now updating components one by one to see what causes this and if it's exclusive to Stretch-based RP (in case everything is updated and the issue does not appear).

Edit 1: I'm starting with the RetroPie Setup script. The bug does not appear yet. (WOW it shows 4.4 :D) let's keep updating...

Edit 2: RetroArch. Obviously no change, as expected.

Edit 3: runcommand... no change. RP conf menu... no change.

Edit 4: Updating EmulationStation... holding my breath... NO CHANGE! :O

Edit 5: Doing a general update, including kernel and other OS packages... nope. Nothing. Everything works perfectly. What a headache :/

[matchaman]

So my "final" conclusion is that, although Raspbian Stretch itself has no issues with omxplayer (and neither does Stretch based RetroPie in console), when omxplayer runs within EmulationStation on a Stretch-based RetroPie, the system goes through a massive slowdown that doesn't go away until rebooting.

The version of every single software is identical except for Jessie and Stretch bases.

It won't be long until people like me who use their system with CRTs for 240p via composite will experience this. The only way to avoid this is to keep using the internal player instead of omxplayer but the results are less good looking, especially for video screensavers that look much better with omxplayer...

[mitu]

@matchaman said in Bug: OMXPlayer on Stretch-based builds stutters on composite:

So my "final" conclusion is that, although Raspbian Stretch itself has no issues with omxplayer (and neither does Stretch based RetroPie in console), when omxplayer runs within EmulationStation on a Stretch-based RetroPie, the system goes through a massive slowdown that doesn't go away until rebooting.
The version of every single software is identical except for Jessie and Stretch bases.

I think your conclusion is contradicted by the next statement

The version of every single software is identical except for Jessie and Stretch bases.

I think that Stretch has a problem with the omxplayer/composite combination (though most likely it's a video driver bug in 4.14), but that problem exhibits only when running with certain parameters. If you can do 1 more test:

1. Repeat the stuttering problem in ES+Omplayer and write down the parameters of the omxplayer command.
2. Reboot the system, exit ES and run omxplayer with the same parameters as if it was run from ES. Does the slowdown/stuttering occurs ?

[pjft]

Nothing seems to suggest any kind of CPU-heavy workload, so - as disheartening as it may seem - there's little to no suggestion I could have here that could help.

There were mentions of the .14 firmware having some troubles, so perhaps trying to install a previous Stretch firmware (.9) might be a good attempt there. Unsure what the exact package do downgrade via apt-get will be, but might be worth a shot.

Another suggestion could be to explore a different memory split - try manually increasing it and see if it changes anything. I don't see why it would, but I've been wrong plenty of other times.

Running sudo vcdbg reloc stats when running omxplayer and ES might suggest how much GPU memory you have available at the time, and if there's anything weird there.

Another alternative may be to file an issue here and see if they have any ideas or hypotheses on how to troubleshoot or address this. Realistically, though, if ES remained unchanged, omxplayer remains unchanged, and the firmware update causes this, we're kind of hands tied given that we don't control the omxplayer development nor the firmware. The only thing we know is that Jessie doesn't work on the Pi3B+, so it needs to move to Stretch - and the upgrade won't be stalled if there's no reasonable alternative at the OS level at this moment.

We will keep exploring this, but the reality is that unless someone that actually has a composite cable and a bit more knowledge of the underlying OS and drivers has the chance to look into this, we may struggle to find something unless omxplayer or the firmware fixes it.

Out of curiosity, where are the videos you're running? SD card? USB drive? NAS?

On a side note, thank you @mitu for the fantastic job you've been doing these last few weeks/months in helping everyone out in the forums. I've been meaning to say it to you earlier - great job!

[G.I.Josh]

Hello,

I had to register for this problem. I got my 3+ model and replaced it in my mega drive empty shell. I previously used a 3 model but i always upgrade. I saw that 4.4 was released in final version so i finally use it today (i did not want to use beta version). I am connecting to a tube television with RCA jack and i experience a strange problem. It is abrand new image only with upload of roms+videos.

On carbon video and other theme when a video plays the whole system goes to slow motion!!! Not only video but also any emulator any rom...even music!! But when i use again HDMI 720p that i do tests the bug is not there! Crazy thing...... its like low resolutions get it tired!

I had to change to non-OMX player but then the theme looks deforme and videos play with lag before playback. OMX player works fine before upgrade on model 3 non-plus. Also on same microsd on 3 i get the same problem when i swap. Unfortunatly its not backward compatible.
Note i dont know linux or programming i just use Pi to play and never experience major problems like this. It is the only way (tube television) i play for retro feeling inside a empty mega drive.

Yours,
Joshua

[mitu]

@g-i-josh Something similar to this ? Seems specific to the new Stretch based build - not entirely sure it's RetroPie or Raspbian specific ?

[pjft]

You and @matchaman mentioned something I didn't pick up prior to this. What do you mean by emulators and ROMs also slowing down? Is it when you play the games? Does that only happen if you run omxplayer - meaning if you don't use omxplayer everything runs fine, even the emulators?

Do join the other thread. Thanks.

[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?