Opened 3 years ago

Closed 3 years ago

Last modified 18 months ago

#12819 closed Bug Report - General (fixed)

Enabling time stretch on Raspberry Pi v3 platform causes jerky playback.

Reported by: nemiroal@… Owned by: Peter Bennett
Priority: minor Milestone: unknown
Component: Ports - rPi Version: 0.28.0
Severity: medium Keywords:
Cc: Ticket locked: no

Description

Enabling Time Stretch < 1.0x or > 1.0x causes jerky playback. Using USB based external audio adapter improves playback greatly, but still jerky enough to be annoying. Disabling audio all together has no problem playing fast and looks very smooth at 1.5x. Seems to be some kind of sync issue.

CPU load over a 10 sec sample play the game 1080i content using onboard audio via HDMI output on 720p HDTV.

Time Stretch OFF: 09:24:24 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 09:24:34 PM all 3.60 0.00 2.78 0.00 0.00 0.67 0.00 0.00 0.00 92.95 09:24:34 PM 0 3.27 0.00 0.98 0.00 0.00 2.83 0.00 0.00 0.00 92.92 09:24:34 PM 1 2.42 0.00 3.43 0.00 0.00 0.00 0.00 0.00 0.00 94.15 09:24:34 PM 2 4.33 0.00 2.32 0.00 0.00 0.00 0.00 0.00 0.00 93.35 09:24:34 PM 3 4.37 0.00 4.27 0.00 0.00 0.00 0.00 0.00 0.00 91.35

Time Stretch 1.1x: 09:23:24 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 09:23:34 PM all 19.67 0.00 1.48 0.03 0.00 0.46 0.00 0.00 0.00 78.37 09:23:34 PM 0 14.76 0.00 1.15 0.00 0.00 1.88 0.00 0.00 0.00 82.20 09:23:34 PM 1 37.26 0.00 1.81 0.00 0.00 0.00 0.00 0.00 0.00 60.93 09:23:34 PM 2 23.80 0.00 0.30 0.00 0.00 0.00 0.00 0.00 0.00 75.90 09:23:34 PM 3 2.45 0.00 2.65 0.10 0.00 0.00 0.00 0.00 0.00 94.80

Moving content from my BE to target's onboard SD card makes no difference and rules out my wired onboard Ethernet and/or network stack. Performance is the same.

Change History (14)

comment:1 Changed 3 years ago by Peter Bennett

Status: newaccepted

comment:2 Changed 3 years ago by Peter Bennett

I can fix this, but the audio quality during time stretch will not be perfect. Slow down will work with some echo in the sound. Small amounts of speed up will work fine. Speed up to 2.0 will not work well. The raspberry Pi 3 does not have enough power for higher speeds.

comment:3 Changed 3 years ago by nemiroal@…

any improvement would be greatly appreciated. Thank you for looking into this.

comment:4 Changed 3 years ago by Mark Spieth

What it really needs is mmx/vfp equiv for arm assembly routines written. I checked upstream and there is no ARM optimised version (yet). ALternatively we can go back to integer mode which will be faster.

comment:5 Changed 3 years ago by Peter Bennett

I changed some of the settings used for SoundStretch to less demanding ones if ARM is being used. I did not change to integer mode. With the changes I made, it works as I have described above. I used different settings for speed up or slow down, which also helped.

comment:6 Changed 3 years ago by nemiroal@…

looking forward to trying it. Do you have any thoughts on when it may find itself into one of your upcoming pre-build snapshots? I'm not sure what your plans are for the future updates. Thanks again.

comment:7 Changed 3 years ago by Peter Bennett

I will test it for a couple of days then commit it and create a new mythtv-light version.

If I slow down to 0.5 everybody sounds like they are extremely bored and sleepy. If I speed up to 2.0 they are speaking so fast I cannot understand anything.

With the changes I am testing it works best at small changes from 1.0, like 0.9, 0.8 or 1.1, 1.2. If you get too far from 1.0 the sound starts to deteriorate.

What is your use case for the time stretch?

What stretch factor would you expect to use?

comment:8 Changed 3 years ago by nemiroal@…

Thanks for asking. We normally listen at 1.2 or 1.3. Never slower than 1.0. Never faster than 1.3. Sounds like the improvements you have will be just about right for our use case.

comment:9 Changed 3 years ago by e_karlin@…

My default is 1.5 but will watch shows like How It's Made at 2.0 as dialog is less necessary. That said, I've replaced my RPi2 frontend with a Liva but will likely pick up a RPi3 at maker faire this weekend.

comment:10 in reply to:  4 Changed 3 years ago by Karl Egly

Replying to markspieth:

What it really needs is mmx/vfp equiv for arm assembly routines written. I checked upstream and there is no ARM optimised version (yet). ALternatively we can go back to integer mode which will be faster.

I took a peek at the various "let the VideoCore? accelerate your stuff" bits of information out there but had a hard time finding out how/if you can mix QPU programs with OpenGLES and OpenMAX usage.

https://github.com/hermanhermitage/videocoreiv#introduction

https://github.com/mn416/QPULib#qpulib

comment:11 Changed 3 years ago by Peter Bennett

After this fix, slowdown will work for all values down to 0.5x. Speedup will work up to around 1.3 or up to 2.0 depending on the content and your setup.

The limiting factor on increasing speed is the video decoding. With 1080i at 30fps or 720p at 60fps the speedup can go up to around 1.3. Trying to go higher causes jerkiness and slowdown. With 720p at 30fps or 480p, speedup works fine up to 2.0x.

If you need to speed up HD content beyond what works you can first transcode to 720p or less at 30fps or less.

comment:12 Changed 3 years ago by Peter Bennett <pbennett@…>

Resolution: fixed
Status: acceptedclosed

In 8b49d6cb407f827a1a19dff5c96773556f25dcd3/mythtv:

Fix time stretch on Raspberry Pi.

Fixes #12819

comment:13 Changed 3 years ago by Peter Bennett <pbennett@…>

In 07a52a0b421b20b32716d5cb10a22c7a2bef4116/mythtv:

Fix time stretch on Raspberry Pi.

Fixes #12819

(cherry picked from commit 8b49d6cb407f827a1a19dff5c96773556f25dcd3)

comment:14 Changed 18 months ago by Peter Bennett

Owner: changed from Peter Bennett to Peter Bennett
Note: See TracTickets for help on using tickets.