• 1
  • 153
  • 154
  • 155(current)
  • 156
  • 157
  • 260
Intel NUC - Haswell (4th Generation CPU)
(2014-02-24, 22:25)gamble Wrote: Finally got a log while my problem triggers and movies begin to stutter again and freeze, here
Is the link :

http://xbmclogs.com/show.php?id=138053

So after having Fritsch taking a look at my log he told me that my problems seem to
be triggered by handshake problems between the NUC and my AVR.
Didn't encounter any problems the last 2 days by getting sure the AVR gets compl. booted
BEFORE i start the NUC.
Reply
(2014-02-26, 17:38)fritsch Wrote: Yes. Enable it and follow the osd - haswell will pretty well do exactly 23.976 fps with it enabled.

And just to triple check, you recommend to enable this option (on Gotham) even when bitstreaming HD Audio to the AV receiver?
Reply
I haven't been following this thread very closely - I've read the last 5-10 pages or so, but couldn't bring myself to read all 155 pages, so sorry if this has already been discussed:

I'm having a few issues with my i3 haswell nuc (win8.1, xbmc + wmc, 2x2gb ram, 120gb ssd, NUC -> Denon 3312 AVR -> Panny plasma connected by HDMI):
1) In XBMC, when I try to do DTS-HD passthrough via HDMI (mkv file), the movie stutters like crazy - completely unwatchable. I followed suggestions on another thread and uninstalled Realtek driver but that didn't help. Plays fine if I select "analog" for the audio output. Is there a significant downside to doing analog vs HDMI?
2) My Harmony 800 remote does everything as expected, EXCEPT powering on/off. It doesn't seem to do anything.
3) I have windows go to sleep after 30min of inactivity. Sometimes when I turn back the TV & AVR back on, I just get a "no signal" message. Wiggling the mice, tapping on the keyboard, etc doesn't seem to do anything. I have to turn the NUC off and on again (with the physical button on the NUC) to fix this.


Any suggestions on any of the above? Thanks!
Reply
regarding 1) are you using WASAPI for sound output? I have found that DirectSound prudces bad stuttering while WASAPI works well. I am not on a NUC but it may help you anwyay
pvr.wmc TV addon and ServerWMC Backend Development Team
http://bit.ly/ServerWMC
Reply
(2014-02-27, 03:34)scarecrow420 Wrote: regarding 1) are you using WASAPI for sound output? I have found that DirectSound prudces bad stuttering while WASAPI works well. I am not on a NUC but it may help you anwyay
Thanks for the suggestion. It was indeed set to DirectSound. Setting it to WASAPI fixed it!! (I'm very much a noob at this sort of thing, so I really appreciate your help. Still need to sort out the harmony remote/power issue, but I'm very satisfied with this NUC so far now that DTS-H MA passthrough is working. Yay!
Reply
Got my NUC (D54250WYB) today & sorted out a few things I had to work-around:
I'm running XBMC in Linux Mint
Had to use Mint 15 because the latest driver for my Wireless Adapter won't load on Mint 16 (or any kernel >3.10)
But I found there was no sound, although I got video output with no problems
Booted off a live boot version of 16 and the sound was fine in that
Further research suggested that HDMI would not work with Kernel <3.10
However I was able to find a fix:

Code:
sudo add-apt-repository ppa:ubuntu-audio-dev/alsa-daily
sudo apt update
apt install oem-audio-hda-daily-dkms

Reboot, then go to menu/preferences/sound and now you will find HDMI option to select.

So for anyone having similar problem, there you go.

Mint 16 or Ubuntu 13.10 have this already embedded so no need to add there,

Got all the settings in xbmc figured out & all is working great - I like the Confluence Customizable Mod so far and comfortable with my way around it.

One remaining issue is to sort out the shut-down - it immediately wants to re-start;
I recall seeing something about that (not sure if in here or somewhere else) so I'll get searching on that
Updated to the latest Bios but no difference there
Meanwhile if someone who has been there can point me, that would be great

edit - found this - https://communities.intel.com/thread/47751
I need to study it further - right now I have disabled wake on LAN and it no longer restarts unprompted when shut down.
Needs the power button to restart (which is no big deal for me, but would be nice to have it start off IR)
Reply
(2014-02-26, 18:55)fritsch Wrote: Works perfectly fine on my Haswell Celeron 1820T with gotham of course. Frodo was a nightmare :-)

Hm, guess I need to try it again. I believe I was on Frodo when I tried "sync playback to display" last, it caused horrible sound issues while bitstreaming HD audio.

I get very few dropped frames with that option disabled though, that's why I recommended it. I'll report back once I've tried it on latest Gotham.
Reply
Remember: That setting makes only sense, if it is combined with Adjust Refreshrate to match video. It's quite stupid to Sync Playback to Display, when content has 24 or 23.9758 fps and Display is running at 60hz.

Edit:
Perhaps something to add. Passthrough sucks from a sync point of view :-) If video is not encoded properly, e.g. some frames missing from time to time, wrongly converted, so that video and audio slowly get out of sync, the only chance with passthrough is to "drop" or "duplicate" packages. Those packages are mostly of 32ms time and those are "raw" packages, just a bunch of data xbmc does not touch at all.

Syncing decoded streams e.g. dts or truehd or ac3 as lpcm (this conversion is lossless(!)) is much easier, as you can do a little bit of resampling to speed up or speed down without sacrificing the sync.Sadly there is no OSS DTS-HD Master audio decoder yet and the DTS-Core is used instead.

Out of that reason some people choose "Audio Clock" for sync. There we can skip, drop, resync video output which might give "visual stutter" but not audio artifacts.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
(2014-02-27, 13:13)fritsch Wrote: Remember: That setting makes only sense, if it is combined with Adjust Refreshrate to match video. It's quite stupid to Sync Playback to Display, when content has 24 or 23.9758 fps and Display is running at 60hz.

Edit:
Perhaps something to add. Passthrough sucks from a sync point of view :-) If video is not encoded properly, e.g. some frames missing from time to time, wrongly converted, so that video and audio slowly get out of sync, the only chance with passthrough is to "drop" or "duplicate" packages. Those packages are mostly of 32ms time and those are "raw" packages, just a bunch of data xbmc does not touch at all.

Syncing decoded streams e.g. dts or truehd or ac3 as lpcm (this conversion is lossless(!)) is much easier, as you can do a little bit of resampling to speed up or speed down without sacrificing the sync.Sadly there is no OSS DTS-HD Master audio decoder yet and the DTS-Core is used instead.

Out of that reason some people choose "Audio Clock" for sync. There we can skip, drop, resync video output which might give "visual stutter" but not audio artifacts.

yesterday night I tried to watch 2 movie-show with, off course, the Adjust Refreshrate to match video ON, and the Sync Playback to Display ON (I never used this option before) with drop/dupe Sound option : it's true that I had NO stuterring ; usually, I always had few and smal stuttering while watching (I guess I am very sensitive about that).

I heard no silence or click or something strange, But it seems to me that the sound had a less poor quality : is that possible ? How the sound can be affected by this option ?
Reply
Nope, not possible. If it was passthrough, we don't touch it at all. We eat data packagewise and just put it on the sink, it does not take any stages.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
(2014-02-27, 15:00)fritsch Wrote: Nope, not possible. If it was passthrough, we don't touch it at all. We eat data packagewise and just put it on the sink, it does not take any stages.

Yes it was Passthrough (Dolby Digital 5.1 decoded by my Yamaha A/V). OK, i will try to make better tests for myself. Thanks Fritsch.
Reply
(2014-02-27, 15:00)fritsch Wrote: Nope, not possible. If it was passthrough, we don't touch it at all. We eat data packagewise and just put it on the sink, it does not take any stages.

Sorry to disturb, but for my perfect understanding, with Sync Playback to Display ON with drop/dupe Sound option, it means that if my plasma TV is 24hz and if my video is 23,9758 fps, so the video will be slow down or speed to match exactly 24 fps without stuttering and some small packet of sound (32ms) will be erased or duplicate to synchronise sound and the new video speed ? Am I right ?
Reply
@fritsch

As you know OE 4.0 by default do 175ms audio delay, shall i set it to 0ms while using Sync Playback to Display drop/dupe?

thank you
LG OLED65C8 / Denon AVR-X3200W / KEF E305+ONKYO SKH-410 / Synology DS2415+ / Logitech Harmony Companion / ZOTAC MAGNUS EN1060K (Kodi DSPlayer x64) / LightSpace HTL, DisplayCal, HCFR, Calman / i1D3 OEM Rev.B, i1PRO2 OEM Rev.E
Reply
No - that has no relevance at all. Those delay is a constant offset, which was found by "experimenting", e.g. we asked approximately 100 users concerning their constant offset for specific samples we posted, we summed that up, removed the outliers and ended at 175 ms. It is not yet fully known where this is coming from. We know for sure that there are TVs out there that need more time when doing 24p / 23.9758 fps content - cause they do additional processing.

LipSync and stuff does not work at all on Linux. Only AMD has implemented it in their radeon drivers, but alsa does not make use of it.

Watch some samples and see if you hear sound after mouth moves or before and find your personal special value :-)

To add: this offset is only used for 24.0 / 23.9758 refreshrate.


Edit: We thought that Audio Engine (in frodo) was causing this problem and in deed Anssi found a problem in the old AE code, which is fixed in 12.3 (did not resolve all constant offsets) - when we rewrote a complete new AudioEngine for gotham, this problem was not "included" at all - so the "hw based offset" is still one that is part of the cause.

If you want to do it really write. You need drivers that use LipSync and Sound drivers that incorporate that information and application api that can use it for delay - which we don't have, none of that.

Simple Blurayplayers have that spec and use it though - which sucks in comparison.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
@frarev: Will come back to you later. This is not so easily to be explained. I will talk with Bob, who has written that function, to be really sure.

Here we go: http://forum.xbmc.org/showthread.php?tid...#pid336538 - don't get confused by the 1% - which is a critical point here.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
  • 1
  • 153
  • 154
  • 155(current)
  • 156
  • 157
  • 260

Logout Mark Read Team Forum Stats Members Help
Intel NUC - Haswell (4th Generation CPU)7