Bug 10041

Hi David,

When I downloaded the ogg and wave files from the below location :
http://www.music.helsinki.fi/tmt/opetus/uusmedia/esim/index-e.html

to core-image-sato image (MACHINE= genericx86-64)running on NUC (MODEL: DE3815TYKE), it seems to work as expected (no crashes and media player keeps running). 

Could you please share the location of ogg/wav files that was used for testing or output of the file command on those files?
eg:
# file a2002011001-e02-96k.ogg 

a2002011001-e02-96k.ogg: Ogg data, Vorbis audio, stereo, 44100 Hz, ~96016 bps, created by: Xiphophorus libVorbis I (1.0 RC3)

setting status as "Need info"

Image downloaded from: 
http://autobuilder.yoctoproject.org/pub/releases/yocto-2.2_M2.rc1/machines/genericx86-64/core-image-sato-sdk-genericx86-64.hddimg
tested on MODEL:NUC6i5SYH
files are located in DUT at /home/root/ 

These are the files and "file" command results:

file OGG_16bit_Stereo_44.1KHz_128Kbps_60sec\(1MB\).ogg 
OGG_16bit_Stereo_44.1KHz_128Kbps_60sec(1MB).ogg: Ogg data, Vorbis audio, stereo, 44100 Hz, ~128000 bps, created by: Xiph.Org libVorbis I

file OGG_16bit_Stereo_44.1KHz_256Kbps\(ABR\)_60sec\(1.9Mb\).ogg 
OGG_16bit_Stereo_44.1KHz_256Kbps(ABR)_60sec(1.9Mb).ogg: Ogg data, Vorbis audio, stereo, 44100 Hz, ~256000 bps, created by: Xiph.Org libVorbis I

file OGG_16bit_Stereo_44.1KHz_300Kbps_60sec\(2.2MB\).ogg 
OGG_16bit_Stereo_44.1KHz_300Kbps_60sec(2.2MB).ogg: Ogg data, Vorbis audio, stereo, 44100 Hz, ~300000 bps, created by: Xiph.Org libVorbis I

file PCM_16bit_5.1\(Discrete\)_48KHz_4608Kbps_38sec\(21MB\).wav 
PCM_16bit_5.1(Discrete)_48KHz_4608Kbps_38sec(21MB).wav: RIFF (little-endian) data, WAVE audio, 6 channels 48000 Hz

file PCM_24bit_Stereo_48KHz_120sec\(33MB\)_AKM.wav 
PCM_24bit_Stereo_48KHz_120sec(33MB)_AKM.wav: RIFF (little-endian) data, WAVE audio, stereo 48000 Hz

file PCM_8bit_Mono_8KHz_120sec\(1MB\)_AKM\ \(1\).wav 
PCM_8bit_Mono_8KHz_120sec(1MB)_AKM (1).wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 8 bit, mono 8000 Hz

System was reinstalled obtaining the same result. The application blinks and turns off, screen goes to desktop.

Also, attached dmesg results with several attempts at the end lines, it shows libc error messages. 

greetings.

Created attachment 3334 [details]
dmesg100041

(In reply to comment #1)
> When I downloaded the ogg and wave files from the below location :
> http://www.music.helsinki.fi/tmt/opetus/uusmedia/esim/index-e.html
> 
> to core-image-sato image (MACHINE= genericx86-64)running on NUC (MODEL:
> DE3815TYKE), it seems to work as expected (no crashes and media player keeps
> running). 

Hi Maxin,

Did you notice this was with HDMI? you'll need a display that has speakers (at least the one on the right on my desk has them).

(In reply to comment #5)
> (In reply to comment #1)
> > When I downloaded the ogg and wave files from the below location :
> > http://www.music.helsinki.fi/tmt/opetus/uusmedia/esim/index-e.html
> > 
> > to core-image-sato image (MACHINE= genericx86-64)running on NUC (MODEL:
> > DE3815TYKE), it seems to work as expected (no crashes and media player keeps
> > running). 
> 
> Hi Maxin,
> 
> Did you notice this was with HDMI? you'll need a display that has speakers
> (at least the one on the right on my desk has them).

Hi Jussi,

Yes, Noticed that one. Thanks !

I hope it is ok to use that monitor for testing this :)

Can't reproduce the error in NUC (MODEL: DE3815TYKE) with the Image downloaded from the above mentioned location . 

Will try to recreate the error on a MODEL:NUC6i5SYH NUC

Works as expected in NUC5CPYH as well.

Re-created this error at my end using a NUC MODEL - NUC6i5SYH

Created attachment 3365 [details]
gstreamer pipeline debug image

Debugged this error with the help of Sreerenj. It looks like there are two problems:

1. gstreamer crashes with below listed glibc related error while using xvimagesink: 

# gst-launch-1.0 -v filesrc location= a2002011001-e02-128k.ogg ! oggdemux ! queue ! vorbisdec ! tee name=t ! queue ! audioconvert ! "audio/x-raw, format=S32LE" ! audioresample ! alsasink t. ! queue ! audioconvert ! "audio/x-raw, format=S16LE" ! audioresample !  goom ! videoconvert ! xvimagesink

.....
" gst-launch-1.0: symbol lookup error: gst-launch-1.0: undefined symbol: fwrite, version GLIBC_2.2.5"

Using ximagesink or glimagesink instead of xvimagesink works as expected.

2. crappy sound with alsasink. Seems to be related to alsa support in the device

One (crappy) temporary work around is to move libgstxvimagesink.so - as it forces player to choose other working sinks (ximagesink or glimagesink).

ie, booting the device, then move that file to  /tmp or other location.

# mv /usr/lib/gstreamer-1.0/libgstxvimagesink.so /tmp

after this, the player works as expected (with bad sound quality)

Possibly the gstreamer issue:
https://bugzilla.gnome.org/show_bug.cgi?id=767712

In the link a similar crash was fixed in gstreamer, the real problem is still in xv.

(In reply to comment #13)
> Possibly the gstreamer issue:
> https://bugzilla.gnome.org/show_bug.cgi?id=767712
> 
> In the link a similar crash was fixed in gstreamer, the real problem is
> still in xv.

Agree with Jussi here. With gstreamer-1.8.3 release, the application doesn't crash anymore. However, the xvimagesink still doesn't work. The real problem is with xv driver.

*** Bug 10213 has been marked as a duplicate of this bug. ***

*** Bug 10272 has been marked as a duplicate of this bug. ***

> *** Bug 10213 has been marked as a duplicate of this bug. ***
> *** Bug 10272 has been marked as a duplicate of this bug. ***

Both of these were medium+ so this bug should be as well.

I've updated the title to what I think it should be:

* the failure has only been seen on NUC6i5SYH, I'm guessing it's a skylake issue but we should test with another skylake machine to be sure
* issue is not HDMI related, that was a red herring
* issue prevents audio playback, but the problem seems to be in the video effects that mediaplayer plays at the same time.


A workaround might be to disable the video effects -- or does xv end up in the pipeline in any normal video playback case?

Created attachment 3437 [details]
downgrade xvimagesink (work around)

A work-around will be to downgrade xvimagesink.

Built a poky based core-image-sato image (commit: 792c40cbdd6ec6995e2e9b69056f4ea3986195eb) and tested this video in MPV mediaplayer and default gstreamer based Media player. It works as expected (both using xvimagesink).
http://techslides.com/demos/sample-videos/small.ogv

It seems that the video effects created by goom element while playing ogg or wav has problems with xvimagesink.

(In reply to comment #19)
> Built a poky based core-image-sato image (commit:
> 792c40cbdd6ec6995e2e9b69056f4ea3986195eb) and tested this video in MPV
> mediaplayer and default gstreamer based Media player. It works as expected
> (both using xvimagesink).
> http://techslides.com/demos/sample-videos/small.ogv
> 
> It seems that the video effects created by goom element while playing ogg or
> wav has problems with xvimagesink.

If it seems likely that normal video playback works then we could split this into two bugs:
 * mediaplayer audio playback fails
 * actual xvimagesink problem (qoom visualization on skylake) 

That way we could workaround the former right now (I can send a patch to disable visualization in mediaplayer by default): then QA audio testing would not be blocked on this.

We also need to get the latter fixed but that might require upstream attention from xv or driver people...

Sent Jussi's patch for disabling the visualization to oe-core (as a workaround) :
http://lists.openembedded.org/pipermail/openembedded-core/2016-September/126894.html

Fedora has a similar bug on the Skylake hardware: " Video doesn't render properly with Intel Skylake using xv frontend "

https://bugzilla.redhat.com/show_bug.cgi?id=1305369

Removing the driver (xf86-video-intel) seems to fix the problem. visualization and full screen video output using gst-player works as expected.

#smart remove xf86-video-intel

Filed a bug to keep track of this in freedesktop.org.

https://bugs.freedesktop.org/show_bug.cgi?id=97950

Since a workaround is available in oe-core master ( http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=850ded308cd55df6722725c4f8356178ee2ef3ad ), we could downgrade the severity of this bug from Medium+ and keep this open till we have a proper fix.

xf86-video-intel master seems to work fine, and 4e172a38e  "sna/gen9: Quick and dirty implementation" is the commit where it started working. Unfortunately backporting that commit alone did not make things work: there are loads of sna improvements preceding the commit, some of them must be required.

The diff between 2.99.917 (poky version) and 4e172a38e is ~600 commits with 25000 changed lines, almost all them sna related. :(

Options:
1. Decide that this is not a critical problem: So far we only know of gst-player visualizations breaking (but based on bug reports in other distros there are other xvideo failures as well)
2. Don't install (or somehow blacklist) xf86-video-intel on skylake, let modesetting handle it (Fedora does this). This is a big change but only affects skylake users
3. Upgrade to a recent commit tested by other distros. 26f8ab5429a5 from July is in Debian. This risks new bugs on all intel graphics, not just skylake


After release we definitely want to do #3, question is what to do for 2.2...

commit f63e8d2dcb2eed6592d6f90d154afd319335c5c8
Author: Jussi Kukkonen <jussi.kukkonen@intel.com>
Date:   Tue Oct 4 10:17:27 2016 +0300

    xf86-video-intel: Upgrade to recent git
    
    Upgrade from the latest snapshot to a recent git revision.
    Without this xvideo does not work on skylake: Backporting the
    specific fixes turned out to be too complex.
    
    Remove patches that are in upstream already, rebase
    disable-x11-dri3.patch.
    
    Fixes [YOCTO #10041]
    
    (From OE-Core rev: 1e295903c89630d5813a0d924a3da47b52f377ac)

Tested on NUC 6Si5SYH 
Build name: 2.2 rc4
poky commit: 4b94b498e21aeba945fe7e72a6b7c4bb0314fb83
connect system with a monitor with HDMI
.wav and .ogg audio file can be played on Media Player.