INTERACT FORUM
More => Old Versions => JRiver Media Center 25 for Windows => Topic started by: Mark75 on July 08, 2019, 01:16:42 pm
-
Hello,
I have 2 problems playing mediafiles with JRiver:
1. I hear nothing playing flac-files at 44.1, 88.2 and 176.4 hz. Other hz play fine, bitrate is not an issue (16-44.1 & 24-44.1 both have no sound). JRiver does play the files, I see that looking at the equalizer, I just don't hear anything. I've tried Windows Media Player to play a file at 16-44.1, and that works.
2. JRiver doesn't play videofiles at an other framerate than my desktopsetting when 'Display settings automatic change mode' is set to on or custom.
It all used to work fine over the years on my Windows 7 HTPC connected to my Pioneer SC-LX76. I've replaced both devices because of their age when the issues described started popping up. Also my Pioneer supposedly had issues with an Intel driver. Now I have an Intel NUC8i5BEH on Windows 10 Pro as an HTPC, and an Anthem MRX720 as a receiver. And the issue is still there. They're connected by HDMI, and from my Anthem also HDMI to my FHD Samsung TV. I'm running JRiver 25.0.71 64 bit. Audio is set to WASAPI using Intel Display Audio. Channels are set to 5.1 (which is my setup), no upmixing or downmixing. I'm running the latest Intel Graphics Driver for Intel Iris Plus Graphics 655 (26.20.100.6912), and Display Audio (10.27.0.4). My NUC has this videocard on board. This is a DCH driver and it works my NUC. But when I search for NUC-drivers (https://downloadcenter.intel.com/product/126148/Intel-NUC-Kit-NUC8i5BEH), the latest version is 25.20.100.6519.
I don't know what to try anymore. I've tried just about anything. Please help?
Best regards, Mark
-
For the audio problem, you can use MC's DSP Studio > Output Settings to resample those that don't play.
-
using RO Standard or HQ (MadVR) fir video playback?
-
For the audio problem, you can use MC's DSP Studio > Output Settings to resample those that don't play.
Hi Jim,
thank you for your help. I will try this. Could you help me understand why I need to resample whilst previously this wasn't necessary? Both my on-board soundcard and receiver support these hz-rates.
Thank you,
Mark
-
using RO Standard or HQ (MadVR) fir video playback?
Hi Rij, I'v tried both, no difference between the two. I always used RO Standard.
Regards, Mark
-
Have you tried adding a delay to give your display time to change refresh rates? It's in Video options, under Display Options, and is called Wait on Change. Try 5 or 10 seconds.
That might allow the refresh rate to actually change.
-
The video problem sounds like it could be an HDMI handshaking issue. Use the display on the Anthem or TV to see if it will tell you what refresh rate and resolution it's receiving. I would then try MANUALLY changing the desktop refresh rate through your video driver settings, just to see see if the PC's HDMI can sync with the Anthem under those controlled circumstances. If Windows won't set the refresh rate, JRiver won't be able to do it either. Let us know what you get.
The audio problem is strange because 16-bit 44.1KHz is standard redbook audio. It's inconceivable that either the PC or receiver won't accept it. What do your have for your Audio Device settings in MC? Try WASAPI, and if that doesn't work, try DirectSound. It's also possible you might have to try different "Device settings" , which is found right where you select the Audio Device in MC.
Also, go into your Windows control panel, to the sound settings, and check the properties for your audio device on the playback tab. Make sure all the formats you need show as enabled on the supported formats tab. There may also be an "Advanced" tab where you can test different audio formats. If you have options for "Exclusive mode" on the Advanced tab, make sure they are checked.
-
There might (should) be a setting on the Anthem MRX720 that says something like "Don't pass audio through to the TV'. If that is set, the HDMI chain should finish at the Pioneer SC-LX76, and MC should see its capabilities. That is different from the Video Pass-through setting.
I suspect both issues are the HDMI chain, as mentioned above.
You don't say, but you should be using WASAPI Exclusive mode in MC.
-
For the audio problem, you can use MC's DSP Studio > Output Settings to resample those that don't play.
Hi Jim,
resampling works, but I do experience some lag when I play an audiofile. That is, sometimes I miss part of the start from the music. This also happens sometimes when I test the configuration of the audio-device. Do you know what causes this? I've set 'Play silence at startup for hardware synchronization' at 2 seconds. Is that the way to deal with this?
Regards, Mark
-
Have you tried adding a delay to give your display time to change refresh rates? It's in Video options, under Display Options, and is called Wait on Change. Try 5 or 10 seconds.
That might allow the refresh rate to actually change.
Hi Fitbrit,
setting it to 5 seconds and display change set to custom works, but not when I set display change to automatic? Also it seems audio is not quite in sync with video. What are your thoughts on this? With my old Pioneer it was never necessary to set this delay.
Regards, Mark
-
The Anthem might just be slower than the Pioneer in doing the handshake. You could try reducing it to 1, 1.5 or 2s. I've never had equipment that took 5 seconds to sync up, but I haven't had Anthem either...
-
Oops. I meant to refer to the Anthem MRX720 above. Fixed.
Also, what does the Audio Path shows when you play these tracks that are silent? Does it show MC believes that it is playing, or something else?
-
The video problem sounds like it could be an HDMI handshaking issue. Use the display on the Anthem or TV to see if it will tell you what refresh rate and resolution it's receiving. I would then try MANUALLY changing the desktop refresh rate through your video driver settings, just to see see if the PC's HDMI can sync with the Anthem under those controlled circumstances. If Windows won't set the refresh rate, JRiver won't be able to do it either. Let us know what you get.
The audio problem is strange because 16-bit 44.1KHz is standard redbook audio. It's inconceivable that either the PC or receiver won't accept it. What do your have for your Audio Device settings in MC? Try WASAPI, and if that doesn't work, try DirectSound. It's also possible you might have to try different "Device settings" , which is found right where you select the Audio Device in MC.
Also, go into your Windows control panel, to the sound settings, and check the properties for your audio device on the playback tab. Make sure all the formats you need show as enabled on the supported formats tab. There may also be an "Advanced" tab where you can test different audio formats. If you have options for "Exclusive mode" on the Advanced tab, make sure they are checked.
Hi all,
I've set my desktop to 1920/1080@23hz, display change off, and when I play a film @ 23,976 the Anthem shows 1080p24. Also when I set my desktop to 1920/1080@24 hz my Anthem shows 1080p24 when I play a movie @ 23,976. So I guess my hardware is capable, right? Display change set to automatic still doesn't work. The shortest delay that works is 2 seconds.
As for my audio settings, I have it set to WASAPI. That's what MC selects as recommended. Playing flac 16-44.1, audiopath shows:
input 44.1khz 16bit 2ch from source format flac
changes:
playing decoded file from memory
convert from 2 channels to 6 channels
output: 44,1khz 24bit (padded) 6ch using wasapi (direct connection)
When I switch to direct sound, 44,1hz, 88.2 & 176.4 do play ?
When audio device is set to wasapi, disabling event style makes that the file doesn't play. And play a little silence has no effect.
Buffer is set to 100 milliseconds
Bitdepth is set to automatic. When I switch it to 16bit integer, it plays 16-44.11, 24-44.1, 24-48, 24-96, 24-192 under WASAPI. But not 24-88.2 & 24-176.4.
When I check the properties of my audio device, it says:
maximum no of channels: 8
HDCP: supported
bitdepths: 16 & 24
samplefrequencies: all from 32 to 192. I can't enable anything here, it just shows as supported
codecs: DTS Audio, DD Plus, DTS-HD, Dolby TrueHD, Dolby Digital, Dolby Atmos (Dolby MAT 2.0)
On the advanced tab, both checkboxes concerning exclusive mode are set. When testing the different audio formats, I often miss the beginning of the sound on the first speaker, like there is some 'lag'. And 16-44.1, 24-192 do work, but not 24-44.1, 24-88.2, 24-176.4. When I run 'solve audioproblems' for the audio-device, it says 'audio-format not set as standard', and 'solves' it. But I have experienced this often. Also, it resets my speakersettings to stereo.
On my Anthem, I haven't found a setting like "Don't pass audio through to the TV'. Is this like ARC? I can't select HDMI ARC for audio-input at the same with HDMI for my HTPC.
I hope this helps in further diagnosing the issue? For now, it seems Direct Sounds works, but this is a lesser sound-quality, right? Also display setting set to custom and 2 seconds delay works.
I'm curious to see what you think.
Best regards,
Mark
-
I also use Bitstreaming thru HDMI, but I can't use bitstreaming in combination with Direct Sound it appears. That is, I can't play a movie with DTS-HD when audio is set to direct sound with bitstreaming. And that's a pity because my Anthem excels at this point...
-
I've set my desktop to 1920/1080@23hz, display change off, and when I play a film @ 23,976 the Anthem shows 1080p24. Also when I set my desktop to 1920/1080@24 hz my Anthem shows 1080p24 when I play a movie @ 23,976. So I guess my hardware is capable, right?
Maybe, maybe not. 24Hz and 23.976Hz are not the same thing. Unfortunately, some equipment/software shows 23.976 as 24, which makes it difficult to distinguish. When you are running this way, play a 23.976 movie (like a blu-ray) using RedOctober-HQ, and during playback, bring up the MadVR on-screen display. Right at the top it will tell you the accurate display rate.
Your original description was unclear on one point: I know you changed the receiver from Pioneer to Anthem, and that you changed from Windows 7 to Windows 10. Did you actually change the PC hardware to the NUC, or just upgrade the OS?
If you still have the Pioneer, I'd plug it into the NUC and see if the problems go away.
When I switch to direct sound, 44,1hz, 88.2 & 176.4 do play ?
When audio device is set to wasapi, disabling event style makes that the file doesn't play. And play a little silence has no effect.
Buffer is set to 100 milliseconds
Bitdepth is set to automatic. When I switch it to 16bit integer, it plays 16-44.11, 24-44.1, 24-48, 24-96, 24-192 under WASAPI. But not 24-88.2 & 24-176.4.
This is significant.
First, the specs for your NUC say: "Support for 44.1 kHz/48kHz/96 kHz/192 kHz sample rates on all analog inputs". There is no mention of support for 88.2 or 176.4. Maybe that means the spec writer just didn't bother, or maybe those formats don't work.
I looked at the specs for your receiver, and it only says it accepts "up to 192KHz". It does not specifically say it supports 88.2 & 176.4KHz.
I have a different sound card then you, but in my WASAPI bitdepth settings, other than Automatic, only 2 options work:
16-bit integer
24-bit integer in a 32-bit package
When trying to play 24bit files when set to 16-bit, MC plays them, but Audio Path warns the output bitdepth is insufficient. This is undesirable.
I suggest you manually try setting to "24-bit integer in a 32-bit package", and see what you get. I suspect that's what "Automatic" was selecting, based on the Audio Path output you listed before.
It sounds like everything works when using DirectSound, is that right? DirectSound works because windows and the audio driver convert everything to something the sound card can handle when using direct sound. You might have to use DirectSound, unless someone with more low-level knowledge about how MC interacts with WASAPI and the audio driver can think of something else.
Your other option would be to enable JRiver's sample rate conversion in the output format module. Set your WASAPI bit depth for the setting that produces the most compatible results, and then use output format to convert the remaining sampling rates that won't play, 88.2 & 176.4 That might be what DirectSound is doing for you. If your audio device isn't compatible with those formats, resampling as Jim suggested earlier is your only option.
If the above suggestions don't bear fruit, your audio problem is starting to sound to me like an incompatibility between your NUC audio hardware/drivers and JRiver. One of the users here, jmone, has done significant testing of NUCs with JRiver. You might ask him about compatibility issues or necessary tweaks.
-
On my Anthem, I haven't found a setting like "Don't pass audio through to the TV'. Is this like ARC? I can't select HDMI ARC for audio-input at the same with HDMI for my HTPC.
No, they are different things. Not all receivers have an option like that.
But it looks like the problem is definitely that the Intel HDMI driver for your NUC doesn't support 88.2 & 176.4 KHz. It is important to note that it is the "Intel® Display Audio Driver" version (10.27.0.4) or above in the Video Driver you have that is handling audio, and not the onboard soundcard you mentioned earlier. So this;
Both my on-board soundcard and receiver support these hz-rates.
makes no difference. The onboard soundcard isn't being used.
I can't quickly find any sensible information on what your Display Audio driver supports. But Windows will show you what formats are supported if you go to the Properties for the Display Audio device, select the Advanced tab, and click the drop dowwn list in the Default Format area. Something like this image:
(https://forums.intel.com/sfc/servlet.shepherd/version/renditionDownload?rendition=THUMB720BY480&versionId=0680P000005i4PQ&operationContext=CHATTER&contentId=05T0P00000FsO0I)
Audio works using Direct Sound as Wer said, because Direct Sound always converts to a supported format.
Resample 88.2 up to 96, and 176.4 up to 192 KHz in Output Settings. That isn't ideal but should work fine.
Wer, different sound cards and their drivers, or in this case HDMI Audio Drivers, will support different bit-depths. For example, my simple motherboard based Realtek soundcard on my Workstation supports;
32-bit floating point
32-bit integer
24-bit integer (in a 32-bit package)
24-bit integer
16-bit integer
I have always left the Audio Device bit-depth setting at Automatic, which has worked fine and gives MC the most flexibility.
-
Wer, different sound cards and their drivers, or in this case HDMI Audio Drivers, will support different bit-depths.
Yep, I know that. You and I just told him the same thing. ;D
-
Yep, I know that. You and I just told him the same thing. ;D
I figured you did. I was just clarifying (trying to) that there would probably more than two supported formats on his system. The "24-bit integer in a 32-bit package" is probably not the best format to use, unless your options are limited.
I think Auto is best, rather than selecting a specific format, and MC will pick a matching format if it exists.
-
Agreed. I was trying to give him every option to try before resorting to what he seemingly didn't want to do: downsample as Jim originally suggested.
I don't have a NUC to try, so I'm not sure if it definitely doesn't support those formats or not, as the specs could just be imprecisely written. I'd be a little surprised if the Anthem didn't...
-
I don't have a NUC to try, so I'm not sure if it definitely doesn't support those formats or not, as the specs could just be imprecisely written. I'd be a little surprised if the Anthem didn't...
Intel has had issues with HDMI audio on integrated iGPUs for a long time. I think their solution now is to just not share any information about what is supported. I found a little information about the CPU used in the NUC which implied that it would support 88.2 and 176.4 KHz, but again it wasn't clear and seemed to apply only to a certain audio feature. i.e. Silent Streams.
I think it would be worth it for Mark75 to contact Intel support to get the answers. Although the device properties should show what is supported, so maybe after checking that.
-
That's interesting to know. I hadn't heard that. I'd been thinking of acquiring a NUC myself, but might have to reconsider.
Jmone has reviewed a lot of NUCs, and I don't recall him mentioning anything about audio problems. If this thread gets his attention, maybe he will know for certain. I would think he tested all the audio formats...
Edit:
It seems that Intel dropped support for some audio formats in the NUC drivers at some point, but apparently you can use an older driver version where the support was still in place.
The OP might want to look at this thread:
https://yabb.jriver.com/interact/index.php?topic=114843.0
-
Maybe, maybe not. 24Hz and 23.976Hz are not the same thing. Unfortunately, some equipment/software shows 23.976 as 24, which makes it difficult to distinguish. When you are running this way, play a 23.976 movie (like a blu-ray) using RedOctober-HQ, and during playback, bring up the MadVR on-screen display. Right at the top it will tell you the accurate display rate.
--> I've tested and it shows 23,976.
Your original description was unclear on one point: I know you changed the receiver from Pioneer to Anthem, and that you changed from Windows 7 to Windows 10. Did you actually change the PC hardware to the NUC, or just upgrade the OS?
If you still have the Pioneer, I'd plug it into the NUC and see if the problems go away.
--> I actually changed the hardware, that is, I bought a new NUC and a new AVR, the Anthem MRX720. I don't have the Pioneer anymore
This is significant.
First, the specs for your NUC say: "Support for 44.1 kHz/48kHz/96 kHz/192 kHz sample rates on all analog inputs". There is no mention of support for 88.2 or 176.4. Maybe that means the spec writer just didn't bother, or maybe those formats don't work.
--> Does the NUC have analog inputs? ? I've connected it via HDMI. Also, 44,1 doesn't either using WASAPI.
I looked at the specs for your receiver, and it only says it accepts "up to 192KHz". It does not specifically say it supports 88.2 & 176.4KHz.
--> I would be very surprised if the Anthem didn't suppport 44,1 (that one also doesn't work with WASAPI), 88.2 & 176.4
I have a different sound card then you, but in my WASAPI bitdepth settings, other than Automatic, only 2 options work:
16-bit integer
24-bit integer in a 32-bit package
When trying to play 24bit files when set to 16-bit, MC plays them, but Audio Path warns the output bitdepth is insufficient. This is undesirable.
I suggest you manually try setting to "24-bit integer in a 32-bit package", and see what you get. I suspect that's what "Automatic" was selecting, based on the Audio Path output you listed before.
--> I've tried all options, only the last one partially works as mentioned in my previous post.
It sounds like everything works when using DirectSound, is that right?
--> Yep
DirectSound works because windows and the audio driver convert everything to something the sound card can handle when using direct sound. You might have to use DirectSound, unless someone with more low-level knowledge about how MC interacts with WASAPI and the audio driver can think of something else.
Your other option would be to enable JRiver's sample rate conversion in the output format module. Set your WASAPI bit depth for the setting that produces the most compatible results, and then use output format to convert the remaining sampling rates that won't play, 88.2 & 176.4 That might be what DirectSound is doing for you. If your audio device isn't compatible with those formats, resampling as Jim suggested earlier is your only option.
--> In MC I've set 44,1 to 48, 88.2 to 96 & 176.4 to 192 following Jim's advice. That works under WASAPI
If the above suggestions don't bear fruit, your audio problem is starting to sound to me like an incompatibility between your NUC audio hardware/drivers and JRiver. One of the users here, jmone, has done significant testing of NUCs with JRiver. You might ask him about compatibility issues or necessary tweaks.
-
Here's how to quote text.
[ quote ]The question is here. [ /quote ]
and the answer goes here.
I added spaces above. If they are removed, you get this:
The question is here.
and the answer goes here.
-
Mark75, you're giving contradictory information.
First you said this:
it plays 16-44.11, 24-44.1, 24-48, 24-96, 24-192 under WASAPI. But not 24-88.2 & 24-176.4
Then you said this:
I've connected it via HDMI. Also, 44,1 doesn't either using WASAPI
Does 16-bit, 44.1KHz work under WASAPI, or not?
Because that's redbook audio. There is no way either your receiver or the audio hardware in your NUC doesn't support it. It's standard CD audio, and all hardware supports it. Your Anthem definitely does support it.
If you've got things set so that you can't play 16-bit 44.1KHz audio under WASAPI, you've got corrupted or misconfigured drivers or some other software problem. You should never have to resample that format.
-
Hi Wer,
what is said is this:
Bitdepth is set to automatic. When I switch it to 16bit integer, it plays 16-44.1, 24-44.1, 24-48, 24-96, 24-192 under WASAPI. But not 24-88.2 & 24-176.4.
So when bitdepth is set to automatic, I hear nothing playing 16-44.1.
When I set bitdepth to 16bit integer, it plays 16-44.1, 24-44.1, 24-48, 24-96, 24-192 under WASAPI. But not 24-88.2 & 24-176.4.
-
I suggest you take a look at the other thread I referenced above and see if you can find older drivers for your NUC that still support the sampling rates properly.
-
Did you do this?
Do it now. Post an image showing the same information as the Advanced tab.
I can't quickly find any sensible information on what your Display Audio driver supports. But Windows will show you what formats are supported if you go to the Properties for the Display Audio device, select the Advanced tab, and click the drop dowwn list in the Default Format area. Something like this image:
(https://forums.intel.com/sfc/servlet.shepherd/version/renditionDownload?rendition=THUMB720BY480&versionId=0680P000005i4PQ&operationContext=CHATTER&contentId=05T0P00000FsO0I)
I suggest you take a look at the other thread I referenced above and see if you can find older drivers for your NUC that still support the sampling rates properly.
That may indeed be the only solution, but Windows may try to insist on a driver update. Microsoft is moving in that direction.
I honestly don't know what Intel is thinking by not supporting common audio formats in their driver. It defies belief.
-
As an aside, the information shown in the window referred to by Roderick is not always accurate.
For example, on my system, 24/176 is not listed as available for my AMD HDMI output on my Radeon card. But JRiver is happy to play that format via WASAPI without resampling, and my processor confirms it receives it. The Windows control panel is sometimes just flat out wrong. Not surprisingly, that can make diagnosis more complicated.
Things often don't behave the way they ought to in Windows audio, so the best test is always of course "Does it work?" ;D
Roderick, your screenie does not list 24/192. Does that work on your system anyway?
-
The image is not actually my system. I stole an image from the internet. ;D
BTW, I've not seen an issue with using that properties display, when I am using WASAPI Exclusive mode, and have both Exclusive Mode settings selected in that dialogue. But I'm not using HDMI out at the moment, because my old Receiver doesn't support HDMI in. Plus I'm sitting at my Workstation and not my HTPC when I answer these questions. My workstation uses plain old Realtek audio.
-
Hi Fitbrit,
setting it to 5 seconds and display change set to custom works, but not when I set display change to automatic? Also it seems audio is not quite in sync with video. What are your thoughts on this? With my old Pioneer it was never necessary to set this delay.
Regards, Mark
On automatic, it's changing right away, and maybe not giving enough time to do the handshake. With custom and a specified delay there is time. The next step is trying to sync things with a fixed audio-video offset. Try 200 ms as a first approximation, but whether it's +200 or -200 will depend on your hardware I suspect. Then adjust as necessary. Also, adjust for the 120 Hz display setting too.
-
For adjusting Lip Sync - have a look at this on the Wiki Page - even has test files to make it easy to dial it in.
https://wiki.jriver.com/index.php/Lip_Sync
-
The "Wait after change" is very very useful as some devices in the HTPC-->AVR-->Screen drops the HDMI link when changing the refresh rate and one of the side effects of this is if MC has started playing the audio device is not available and hence you get no sound. Start at 0.5sec and keep increasing it till the issue of No Audio is fixed.
-
Ah, jmone! Since you are here, and have tested so many NUCs, could you clue us in on the state of things with regard to outputting audio over HDMI from the NUCs? Are there problems, is everything good at all sample rates, or what?
There seems to be conflicting info on this, and I was interested in getting a NUC myself. I found an old thread that talks about Intel disabling some audio formats in more recent drivers...
What's your expert view? Thanks!
-
I've seen odd stuff on Audio with the NUC at some point over the years (like only showing 16-Bit Audio options), but it just seems to work for me on all the reported supported formats for decoding (not bitstreaming) using MC (see pic). I just tested all of these formats on a NUC all and they were fine. My personal preference is:
- If you don't have more than 7.1 Speakers then don't use Bitstreaming. This way you can use video clock and the audio is decoded by MC not your AVR etc.
- If you do have an speaker setup with more than 7.1 speakers then you have to use bitstreaming for ATMOS/DTS-X Content. To complicate matters you can get a mix of Decoding and Bitstreaming based on the Media Type you are playing but it is not straight forward. Ideally, It would be great if MC could identify if a sound track had ATMOS/DTS-X so you could use the Tools--> Options--> Audio--> Audio Device--> Settings--> Bitsreaming--> Custom and then just check "ATMOS / DTS-X" so you only bitstream these.... but MC uses FFProbe which at this stage can not differentiate between ATMOS and std TrueHD or DTS-X and DTS-HD.
So in summary, audio over HDMI on a NUC works fine, but I'd recommend:
- Don't use bitstreaming unless you have more the 7.1 speakers
- Turn on VideoClock
- Use "Display Settings automatic change mode = Custom" if you have a slow HDMI Sync when changing refresh rates and pick a Wait after change so you don't lose audio
- Use the test patterns from the Wiki to dial in the Lip Sync
= Good to go!
-
Awesome, thanks. That screenshot looks like all the formats one would need.
Can you tell us what driver version you're using to get good results?
The OP here, Mark, is having problems with some sampling rates just not working on his NUC, and Roderick and I are thinking he has driver problems.
-
My NUC is on 10.0.17134.1 dated 11/04/2018 for the Audio Driver FWIW. Keep in mind that HDMI works by advertising what formats the whole chain supports. Older AVR's did a poor job of doing this and sometimes you had to use a HDMI Override on the HTPC....or something like "HDMI Detective" to advertise and keep persistent the formats that could really be used. I've not had to use such hacks for many many years however but I've upgraded all my AVR's since then.
-
Here's how to quote text.
[ quote ]The question is here. [ /quote ]
and the answer goes here.
I added spaces above. If they are removed, you get this:
and the answer goes here.
Thanks Jim, I was struggling how to get this to work!
Mark
-
Hi all,
first, I would like to express my appreciation for all your effort in trying to help me!
Attached you will find a picture of the advanced tab. It shows all necessary formats are supported, including 44.1, and not mentioned in the tech specs, also 88.2 & 176.4.
For adjusting Lip Sync - have a look at this on the Wiki Page - even has test files to make it easy to dial it in.
https://wiki.jriver.com/index.php/Lip_Sync
I will try this tomorrow, great tip!
So in summary, audio over HDMI on a NUC works fine, but I'd recommend:
- Don't use bitstreaming unless you have more the 7.1 speakers
Done
- Turn on VideoClock
Done
- Use "Display Settings automatic change mode = Custom" if you have a slow HDMI Sync when changing refresh rates and pick a Wait after change so you don't lose audio
Done, 2 secs works
- Use the test patterns from the Wiki to dial in the Lip Sync
Will try this tomorrow and report back!
As for the driver, for my Intel NUC8i5BEH the oldest "Intel® HD Graphics Driver for Windows® 10 for Intel® NUC" I found, is v24.20.100.6229 dated 9/26/2018. Can I use other drivers than this? I think I now have a DCH-driver installed, the latest version for the Intel Graphics Iris Plus 655 (v26.20.100.6912 dated 28-5-2019), and Intel recommends not to roll back from a DCH-driver (https://www.intel.com/content/www/us/en/support/articles/000031275/graphics-drivers.html). Now, what to do? Reinstalling Windows 10 Pro to try another graphics driver is a bit drastic
-
If you don't want to mess with the drivers further, you can revert to using sampling rate conversion in the Output Format settings.
-
Having built about 40 Intel-based systems in the the last 15 months or so, specifically to run MC, I can say the following:
176 KHz over HDMI is supported by hardware, but not by Intel drivers. It used to be supported by the drivers about three years ago. But then they dropped support for it. For a while, we continued to run older drivers to get the 176 KHz support, but eventually the price one paid for using older drivers became too great. Now we upsample to 192 as a default. 88.2 is definitely supported.
I have direct experience with running Intel integrated video with the same Anthem receiver. It does need a long delay to do the HDMI handshake. OP might want to see whether a firmware update is available for the receiver, too.
-
To get on the same page I just updated the BIOS/OS/Drivers etc on my NUC to the latest. I still have no issues playing any of the formats including 176KHz over HDMI. Just works for me.
-
FYI - The Audio Driver is reporting as 18/03/2019 / 10.0.18362.1 and here is a screen shot of MC playing DSD sampled to 176KHz and playing over HDMI to a PIO AVR (I also checked the PIO's GUI and it reported it is receiving 176 as well).
-
Thanks for the testing.
-
No probs - I'm thinking there will be some more rounds to get to the bottom of it however given the # of systems fitbrit as built!
-
It seems like audio over HDMI from an Intel iGPU can be summarised as: YMMV
But one thing of note is that;
Mark75 has Display Audio (10.27.0.4) 28 May 2019, which is a DCH driver packaged with Intel Graphics Iris Plus 655 (v26.20.100.6912)
Jmone you have the latest, but it is Display Audio (10.0.18362.1) 18 March 2019, but from which driver package?
So the drivers are different, and Mark75's is more recent based on the numbering. Perhaps some more clarification on the source update methods may help?
-
So mine were the Non-DCH Drivers that were installed as a part of the 1803 --> 1903 Windows OS Upgrade. Post the OS Upgrade I ran both Windows Update and the Intel Driver & Support Assistant till they said it was all updated. This left the NUC on the following versions (according to Device Manager):
- Iris Graphics Plus 640 : v24.20.18362 dated 15/08/18
- Intel Display Audio : v10.0.18362.1 dated 18/03/19
I've now updated to the DCH Graphics Drivers from the standalone installer and now have (as per pic):
- Iris Graphics Plus 640 : v26.20.100.6912 dated 28/05/19
- Intel Display Audio : v10.0.18362.1 dated 18/03/19 (I think is is left over..... Need to check what driver it is using)
- Intel Display Audio : v10.27.0.4 dated 17/05/19
HDMI Audio is still just fine.
-
Having built about 40 Intel-based systems in the the last 15 months or so, specifically to run MC, I can say the following:
176 KHz over HDMI is supported by hardware, but not by Intel drivers. It used to be supported by the drivers about three years ago. But then they dropped support for it. For a while, we continued to run older drivers to get the 176 KHz support, but eventually the price one paid for using older drivers became too great. Now we upsample to 192 as a default. 88.2 is definitely supported.
I have direct experience with running Intel integrated video with the same Anthem receiver. It does need a long delay to do the HDMI handshake. OP might want to see whether a firmware update is available for the receiver, too.
Well, this confirms my previous findings & suspicions that is a driver issue.
I bought the Anthem three weeks ago, and the same day I updated the firmware to v1.4.0.95 which is the latest (https://www.anthemav.com/products-current/series=mrx-series-gen3/model=mrx-720/page=reviews)
Shorter than 2 seconds for 'Wait after change' doesn't work. Is that too long in your opinion? Also, I think this is the NUC to blame, not the Anthem.
Testing the audioformats on 'the advanced' tab:
* 16-44,1 does work, however I miss the first part of the test sound that goed to the first speaker. What causes this?
And strangely 16-44.1 does not work under WASAPI
* 24-88.2 & 24-176.4 do not work
Btw, what does OP stands for?
-Edit- Also 24-44.1 does not work when testing this format on the advanced tab.
But when I change WASAPI to Direct Sound and play a 16-44.1 file, it says this on audiopath:
input 16-44.1 ch flac
playing decoded file from memory
convert from 2 channels to 6 channels
output 24-44.1 6ch using direct sound . And I DO have sound??
-
So mine were the Non-DCH Drivers that were installed as a part of the 1803 --> 1903 Windows OS Upgrade. Post the OS Upgrade I ran both Windows Update and the Intel Driver & Support Assistant till they said it was all updated. This left the NUC on the following versions (according to Device Manager):
- Iris Graphics Plus 640 : v24.20.18362 dated 15/08/18
- Intel Display Audio : v10.0.18362.1 dated 18/03/19
I've now updated to the DCH Graphics Drivers from the standalone installer and now have (as per pic):
- Iris Graphics Plus 640 : v26.20.100.6912 dated 28/05/19
- Intel Display Audio : v10.0.18362.1 dated 18/03/19 (I think is is left over..... Need to check what driver it is using)
- Intel Display Audio : v10.27.0.4 dated 17/05/19
HDMI Audio is still just fine.
So, now we're on the same drivers and it works for you but not for me.... What could explain this? Difference in hardware?
-
Shorter than 2 seconds for 'Wait after change' doesn't work. Is that too long in your opinion? Also, I think this is the NUC to blame, not the Anthem.
From what I have experienced it is the Monitor/TV/PJ attached to the AVR that causes HDMI wait to be extended. I have no issues on PC Monitors or TV's but I have to add a 3 sec wait for the HTPC feeding a JVC PJ (and it is not a nuc but a high speced HPTC).[/quote]
Testing the audioformats on 'the advanced' tab:
* 16-44,1 does work, however I miss the first part of the test sound that goed to the first speaker. What causes this?
Just the time it takes to setup the link. You will not notice this in real life just in the Windows Test thingie
And strangely 16-44.1 does not work under WASAPI
* 24-88.2 & 24-176.4 do not work
All these work for me.... but don't worry. Pick one that does work for you and enjoy this music!
Btw, what does OP stands for?
Original Post
-Edit- Also 24-44.1 does not work when testing this format on the advanced tab.
But when I change WASAPI to Direct Sound and play a 16-44.1 file, it says this on audiopath:
input 16-44.1 ch flac
playing decoded file from memory
convert from 2 channels to 6 channels
output 24-44.1 6ch using direct sound . And I DO have sound??
You want to use WASAPI where you can.
-
Hi jmone,
From what I have experienced it is the Monitor/TV/PJ attached to the AVR that causes HDMI wait to be extended. I have no issues on PC Monitors or TV's but I have to add a 3 sec wait for the HTPC feeding a JVC PJ (and it is not a nuc but a high speced HPTC)
The one thing I did not change in my setup is my FHD Samsung TV. And when I had my previous Windows7 HTPC and Pioneer SC-LX76, I didn't have to set a wait for change. But then again, maybe the Pioneer was quicker in this.
Also, I didn't change the HDMI-cables. They're all Audioquest Forest which I bought somewhere around 2012-2013. I don't know which version, but I suspect 1.4. FHD played fine. Could this be an issue? Both the NUC and the Anthem have HDMI2.0a-ports.
Just the time it takes to setup the link. You will not notice this in real life just in the Windows Test thingie
I wish, but sometimes I also miss the first part of the music playing.
You want to use WASAPI where you can.
What I wanted to point-out, is that Windows Test Thingie :D gives me no sound when testing 24-44.1, but when I play a 16-44.1 flac under Direct Sound with MC, audiopath shows that the output is 24-44.1 and I DO have sound. And that's what struck me: why is that ?
But maybe you're right and maybe I shouldn't want to dive in too deep, pick something that works and enjoy the music, but I just can't stand it when things don't work like they should. Especially when things worked fine and all of a sudden it doesn't anymore.
-
Sorry - Forgot to say than when using DirectSound, Windows is Resampling the audio stream. So MC might be putting out 24-44.1 but then Windows takes that output from MC and resamples it to whatever you have set in the Windows Audio System then sends that stream to your AVR. With WASAPI Direct, it sends it from MC straight through to the AVR untouched.
What I don't get is why I can (and always have) been able to play all supported audio formats from my NUC (and all my other HTPCs with other GPUs) yet yours seems to be so finicky. I've tested on many generations of Yamaha AVR and for this on a cheapie Pio.
-
...and your HDMI cables do not impact the audio. They "may" impact the ability to output Video @ UHD with high frame rates.
-
No probs - I'm thinking there will be some more rounds to get to the bottom of it however given the # of systems fitbrit as built!
2 caveats on my last post:
1. All our motherboards are Gigabyte ones
2. I haven't tested this again in recent months
Therefore your post is very interesting. I'll check if we can reproduce the results, hopefully this weekend.
-
My Anthem is running the latest firmware, my TV as well, and the NUC runs the latest BIOS.
--edit--
Just checked for updates and there was a new BIOS. Installed it, but no effect on this issue.
-
The MRX 720 is shown as the Audio Device is MC, isn't it?
With a similar problem last year, the TV (a VIZIO E-Series 60” Class Razor LED™ Smart TV | E601i-A3) was showing up as the Audio Device, as per the image below. I don't think that is the issue here, but just wanted to check, since you and Jmone are on the same drivers with different results. Maybe your FHD Samsung TV is part of the problem.
(https://yabb.jriver.com/interact/index.php?action=dlattach;topic=117404.0;attach=29030;image)
That image is from a couple of posts above this post: https://yabb.jriver.com/interact/index.php/topic,117404.msg813453.html#msg813453 You may want to do a little light reading through that post and thread to understand a bit more what is going on.
BTW, what model is your FHD Samsung TV?
Also, how do you control the NUC? Do you use a wired keyboard and mouse, a wireless keyboard+mouse, use a Remote Desktop application into it, or use a Remote Control App?
Regardless, try this, if you have one of the remote control Apps (See below), or can get one. Well, anyone can get Panel, so I guess that is an easy answer.
1. I assume that you have the NUC set up on boot to start MC with Windows? If not, do that, in MC Startup options. With or without Media Server, but with Media Server turned on and note the Access Key.
2. Set up a Playlist with samples of each of the formats that aren't working now. Or all formats if you wish.
3. Make sure MC is still set to play in WASAPI Exclusive mode, as per above testing which didn't work. Make sure that the "Player" Zone points to the MRX 720, just to make things easier.
3. Get the App you are going to use, if you don't already have one, and check that it will connect to the server and play files in a Playlist to the MRX 720. Test with a format that you know works now.
3. Shut down, and fully power down the TV, AVR, and NUC.
4. Disconnect the HDMI cable from the MRX 720 to the TV, leaving the HDMI cable from the NUC to the MRX 720.
5. Restart everything, and wait a few minutes for everything to settle down.
6. Use the remote you selected to connect to the NUC MC Server, set the output to "Player" or the MRX 720, open your Playlist and test a format that doesn't normally work.
Did it work? Try all the formats. Do they all work now?
If all the formats worked now, then the problem is your Samsung TV, and the HDMI chain. MC is being told the capabilities of the TV instead of the MRX 720.
You just need a Remote Control App that can connect to the NUC MC Server, can send output to the MRX 720 Audio Device, and plays at least one format.
On another PC
Panel in a browser, which is probably easiest, and allow you to connect to a MC Server, and select play to "Player" or any Audio Device on the Server.
Tremote (https://wiki.jriver.com/index.php/Remotes)
iPhone
Panel in a browser.
JRemote if you own it. No trial version. Although I have never used that, so I'm not sure how easy it would be to use for this testing. I assume it would be fine.
MO 4Media (https://yabb.jriver.com/interact/index.php/topic,119879.0.html) for iOS if you don't have any other App. It has a free version that will play three songs in a Playlist. Enough for testing, with just a restart of the App to allow another set of three to be played.
Android
Panel in a browser.
JRemote for Android if you own it. No trial version. Although I have never used that, so I'm not sure how easy it would be to use for this testing. I assume it would be fine.
MO 4Media (https://yabb.jriver.com/interact/index.php/topic,114964.0.html) for Android. Same trial version restrictions as above, but works fine for this testing.
Gizmo
-
The MRX 720 is shown as the Audio Device is MC, isn't it?
Yes, it is. See the attached screenshot 'audio.jpg'. What stands out to me, is the prefix "2-". On Windows 7 to my Pioneer it just showed 'Intel Display Audio", not the "2-" prefix.
That image is from a couple of posts above this post: https://yabb.jriver.com/interact/index.php/topic,117404.msg813453.html#msg813453 You may want to do a little light reading through that post and thread to understand a bit more what is going on.
Interesting read, and it definitely helps understanding how things work, but I don't see the parallel with my situation? I have connected the NUC --> AVR --> TV all by HDMI, and in that order. It's also not a multi-channel problem; just sample-rates 44.1, 88.2 & 176.4 don't have sound, the rest (48, 96, 192) does play normally, regardless whether it's stereo or multi-channel.
BTW, what model is your FHD Samsung TV?
It's a Samsung UE46ES7000SXXN
Also, how do you control the NUC? Do you use a wired keyboard and mouse, a wireless keyboard+mouse, use a Remote Desktop application into it, or use a Remote Control App?
When everything works as it should, I use the EOS-app as a remote on my Android-tablet (Galaxy Tab S2). Works like a charm. As a backup, I also have a wireless keyboard with touchpad. Also I have Teamviewer installed, so I can access the NUC from my desktop.
Regardless, try this, if you have one of the remote control Apps (See below), or can get one. Well, anyone can get Panel, so I guess that is an easy answer.
1. I assume that you have the NUC set up on boot to start MC with Windows? If not, do that, in MC Startup options. With or without Media Server, but with Media Server turned on and note the Access Key.
Yes, I've set Run on Windows startup to 'Media Center'. I've tried Media Center and Media Server' but then I couldn't connect with EOS or Panel to MC ? Then I set it back to 'Media Center' and I had access again with EOS (I didn't try Panel again).
2. Set up a Playlist with samples of each of the formats that aren't working now. Or all formats if you wish.
3. Make sure MC is still set to play in WASAPI Exclusive mode, as per above testing which didn't work. Make sure that the "Player" Zone points to the MRX 720, just to make things easier.
3. Get the App you are going to use, if you don't already have one, and check that it will connect to the server and play files in a Playlist to the MRX 720. Test with a format that you know works now.
3. Shut down, and fully power down the TV, AVR, and NUC.
4. Disconnect the HDMI cable from the MRX 720 to the TV, leaving the HDMI cable from the NUC to the MRX 720.
5. Restart everything, and wait a few minutes for everything to settle down.
6. Use the remote you selected to connect to the NUC MC Server, set the output to "Player" or the MRX 720, open your Playlist and test a format that doesn't normally work.
Did it work? Try all the formats. Do they all work now?
No, the problem is still the same. Also, when I set the output to the MRX720, the AVR switched HDMI-input to DTS Play-fi so I couldn't compare.
What I did try, is connect with the DTS Play-Fi app to my NAS (a Synology DS418) using the Media Server option, with DTS Play-Fi set to Hi-Res Audio, and then I tried the problematic formats again. And 44.1 & 88.2 played fine. 176.4 also played, but with a frequent stutter. 48, 96 & 192 also played without problems. I've checked the sample-rates with the (i) button on the MRX remote, and it stated the right sample-rates (DTS Play-Fi does downsample when not set to Hi-Res Audio).
-
Having built about 40 Intel-based systems in the the last 15 months or so, specifically to run MC, I can say the following:
176 KHz over HDMI is supported by hardware, but not by Intel drivers. It used to be supported by the drivers about three years ago. But then they dropped support for it. For a while, we continued to run older drivers to get the 176 KHz support, but eventually the price one paid for using older drivers became too great. Now we upsample to 192 as a default. 88.2 is definitely supported.
I have direct experience with running Intel integrated video with the same Anthem receiver. It does need a long delay to do the HDMI handshake. OP might want to see whether a firmware update is available for the receiver, too.
I'm starting to believe it is the Anthem in this chain that causes the need for delay. Another problem I experienced when my daughter was viewing Netflix, is the following. Cable-box is also connected to AVR, which is connected to the TV. She watched a show with 5.1 audio with the AVR off (and passthrough on) and the sound stopped after a few seconds. When I switched the audiostream to stereo, it played without a problem. I dove into the soundsettings from my cablebox and found I could set a delay for HDMI-sound. The first step was 40ms which I set. And then multi-channel played with no problems with the AVR off. Also, I experienced something similar when we watched an episode with the AVR on. Sometimes Netflix lost connection and had to reload. And when that happened, we also lost sound. I haven't experienced that either since I set the delay. I think I'll ask Anthem for an answer.
-
I wondered about the "2-" prefix on the audio driver as well, as I noticed it earlier in your audio device properties image. Usually that might indicate that there are two HDMI ports on the PC, but the NUC only has one. Could you have two drivers installed at the same time? That probably wouldn't show in Device Manager. I'm not sure how to check off the top of my head. Also, the NUC does support up to 3 monitors, via Thunderbolt, so it may have something to do with that.
Maybe you could try deleting the audio device in Device Manager, rebooting and letting Windows reinstall the driver. But that is pretty drastic. I would create a System Restore Point, and make a full system backup and have a way of restoring it before trying that. It probably makes no difference anyway.
In the other thread the user also had a NUC > AVR > TV, and his issues were HDMI chain reporting, or more specifically EDID reporting over HDMI. A bit different though, as his TV showed up as the audio device.
Yes, I've set Run on Windows startup to 'Media Center'. I've tried Media Center and Media Server' but then I couldn't connect with EOS or Panel to MC ? Then I set it back to 'Media Center' and I had access again with EOS (I didn't try Panel again)
Okay, that is just weird. I would suspect a firewall issue, or maybe antivirus. But that shouldn't happen. Something for another time though.
No, the problem is still the same. Also, when I set the output to the MRX720, the AVR switched HDMI-input to DTS Play-fi so I couldn't compare.
Sorry, that is confusing. How did you confirm that the same problem exists, if when you switched to the MRX720 the AVR switched to the DTS Play-fi input. I assume that MC was always set to the MRX720, so no switching of output was required, and that when the AVR switched the input to DTS Play-fi that you switched it back to the PC and hence MC? Or is something else going on?
As the DTS Play-fi connection to the AVR seemed to play the tracks successfully, are you able to connect directly from the PC to the TV, and test again? Only playing stereo tracks of course, but all sample rates. The TV is supposed to support stereo FLAC files, but it is a bit hard to find what sample and bit rates it supports, and Samsung warns audio won't play if it is "above the TV’s compatibility ratings", which they then don't document. I couldn't find any reference to what it actually supports.
I think I'll ask Anthem for an answer.
That's probably a good idea, but you might want to try the direct connection to the TV first, which eliminates the MRX720 from the audio path. If that works, you have more to discuss with Anthem.
Also the issues you saw with the Cable box and Netflix could still be the TV being slow to respond to HDMI calls.
-
you might want to try the direct connection to the TV first, which eliminates the MRX720 from the audio path
Don't be surprised if when you try this the audio problem gets worse. I would expect the Anthem to support all of the audio sampling rates we're discussing, and even though the Anthem manual is sketchy on this point, I'd think them rather cheap if they didn't.
On the other hand I would fully expect a TV to NOT support many of the more unusual sampling rates. TV's have to reproduce 44.1KHz because everything does, and 48KHz because that's what's used for video, and not much else. For a TV to grok 176KHz would be pure gravy.
-
It's a test, to see if the same problem occurs, or something different. Worse is definitely a possibility. It may highlight that the NUC driver is capable of some formats.
-
Agreed of course. I meant it more as a "don't panic if" for the OP. Solving problems in this thread has been a bit of whack-a-mole...
-
It's got to be a downstream issue from the NUC, as you had it working with a PIO (and I've no issues with Yami's and Pios's ). The other option is to grab a drink, settle in and listen to some content with MC remixing to something that works (like 96/24) and call it a day :) [flame suit] as I'm certainly can not hear a difference between these "better" sampling rates and bit depths. [/flame suit]
Nyquist–Shannon sampling theorem says the sampling frequency must be greater than twice the maximum frequency one wishes to reproduce. Since human hearing range is roughly 20 Hz to 20,000 Hz, the sampling rate had to be greater than 40 kHz.
-
It's got to be a downstream issue from the NUC, as you had it working with a PIO (and I've no issues with Yami's and Pios's ). The other option is to grab a drink, settle in and listen to some content with MC remixing to something that works (like 96/24) and call it a day :) [flame suit] as I'm certainly can not hear a difference between these "better" sampling rates and bit depths. [/flame suit]
I didn't get the NUC to work with the Pioneer, because I replaced my old Windows7 HTPC for a NUC and the Pioneer for the Anthem at the same time. This is an Intel-driver issue. Troubleshooting over a month is not what I expected when buying a brand new NUC. It should work flawlessly. I have serious doubts concerning the reliability since 16-44.1 is not even supported at this point. And What's next? Since this is the second Intel-audioproduct in a row that let's me down, I've decided to return the NUC to the seller. Fortunately this was no problem. And I'm going to assemble a new system. But definitely not with an Intel-audio chipset.
So.... what's the alternative? I think it should be 4K-capable, considering I might upgrade to a 4K-telly next year. And supporting HDR. In this thread (https://yabb.jriver.com/interact/index.php/topic,114843.0.html) The Big Labinski advises Realtek for audio as the best option. Do you agree?
Also, here https://wiki.jriver.com/index.php/Windows_System_Requirements this is the recommended system:
Intel Core i5 (Quad-Core) or better
Windows 7/8.1 (32 or 64 bit) or newer
4GB of RAM
AMD Radeon HD 6770, Nvidia GTX 550, or better GPU
Solid state (SSD) boot drive for installation and Library files.
Theater View quality settings can be modified via: Options > General > Video Card
Is this still current?
-
Hi Roderick,
Sorry, that is confusing. How did you confirm that the same problem exists, if when you switched to the MRX720 the AVR switched to the DTS Play-fi input.
That's indeed confusing :-) What I meant is, I tested with the zone set to 'player' and I had the same problem. When I switched the zone to the MRX720, the MRX720 switched to the DTS-PlayFi, which is another HDMI-port. And downsampled the signal. As an extra test, I set DTS Play-Fi to Hi-Res Audio, and then I got the results as described. I hope this is more clear?
-
I didn't get the NUC to work with the Pioneer, because I replaced my old Windows7 HTPC for a NUC and the Pioneer for the Anthem at the same time. This is an Intel-driver issue. Troubleshooting over a month is not what I expected when buying a brand new NUC. It should work flawlessly. I have serious doubts concerning the reliability since 16-44.1 is not even supported at this point. And What's next? Since this is the second Intel-audioproduct in a row that let's me down, I've decided to return the NUC to the seller. Fortunately this was no problem. And I'm going to assemble a new system. But definitely not with an Intel-audio chipset.
So.... what's the alternative? I think it should be 4K-capable, considering I might upgrade to a 4K-telly next year. And supporting HDR. In this thread (https://yabb.jriver.com/interact/index.php/topic,114843.0.html) The Big Labinski advises Realtek for audio as the best option. Do you agree?
Also, here https://wiki.jriver.com/index.php/Windows_System_Requirements this is the recommended system:
Intel Core i5 (Quad-Core) or better
Windows 7/8.1 (32 or 64 bit) or newer
4GB of RAM
AMD Radeon HD 6770, Nvidia GTX 550, or better GPU
Solid state (SSD) boot drive for installation and Library files.
Theater View quality settings can be modified via: Options > General > Video Card
Is this still current?
A much lighter system would usually work fine for normal audio (less than DSD).
-
A much lighter system would usually work fine for normal audio (less than DSD).
Playing DSD directly requires very little CPU power. Converting PCM to DSD is what requires a good CPU.
-
Mark, I'm surprised we couldn't get the NUC to work, as jmone has had such good results with them, but such is life.
I can make two recommendations based on personal experience:
1. Realtek chipsets work beautifully for audio.
2. AMD video cards (Radeon) work very well for audio/video over HDMI.
I initially chose AMD over Nvidia for HTPC use because a few years back AMD was better at accommodating the various refresh rate changes and deinterlacing methods than Nvidia was. Perhaps that has changed now and Nvidia is equally as good for HTPC, but someone with current Nvidia experience would have to comment.
I've heard good things about the chipsets for AMD Ryzen platforms, that are available for small form factor PCs, but I have no direct experience with them for HTPC use. Jmone or Fitbrit might know more about the Ryzen compatible chipsets.
It didn't sound to me like your Anthem was behaving as well as the Pioneer did... I have my HTPC hooked up to a Yamaha CX-A5000 processor and have zero issues, but admittedly that device is extremely high end so perhaps that skews the results.
-
It is a shame to give up, but perfectly understandable.
Those recommendations are a bit out of date, if 4K HDR is to be supported.
You will need to go Windows 10 these days, and that means more memory than 4GB. Personally, at current prices, I still wouldn't put in less than 16GB for Windows 10.
I use a nVidia GTX 1060, which was the minimum required for good 4K HDR support back when I bought it. I wanted 3D support as well, and nVidia still did that best. They have dropped 3D support in the latest drivers though.
People are saying good things about the latest AMD Ryzen™ Processors with Radeon™ Vega Graphics, but I haven't looked into them.
-
Yes, I should have said, I don't do 4K on my system. My viewing distance is 14ft from my TV, so 4k is irrelevant at that distance without a projector. Mine system does do 3D nicely though.
Don't Nvidia cards still have problems doing 23.976Hz for blu-ray accurately? I heard they stutter...
If you want to do 4K with MadVR, you will need a beefy graphics card. But be sure you can actually see 4K. Look at an online viewing distance calculator to see what screen size the human eye needs to resolve 4K at your viewing distance.
The tradeoff with getting a beefy graphics card so that you can do fancy MadVR upscaling to 4K is noise. If it's an HTPC for use in the living room, you want something quiet.
My OLED is a 4K panel, because they all are, but I let the TV do the upscaling. I've found the TVs usually do better upscaling than other components, with less fuss. System requirements are much lower if you stick with 1080p video.
The Realtek audio recommendation is still good if you're audio centric.
8GB RAM will work fine for an HTPC, but 16 is better if you're going to use it for other things.
-
Don't Nvidia cards still have problems doing 23.976Hz for blu-ray accurately? I heard they stutter...
Not that I have noticed. But maybe that is just my eyes!
I have many BD full folder rips at 23.976 (MC displays them as 23.98 fps in tags) that play just fine.
My viewing distance is about 4 metres (13 feet), so I am well over the recommendations. I plan to reduce that a bit when I wall mount the TV... one day. I used to let the TV upscale to 4K, but now I do it with MadVR, which appears very slightly better. Basically, I started using MadVR for all resolution control, where possible, and 3D support.
I chose the "NVidia MSI GeForce GTX 1060 GAMING X" in my signature because it has very quiet fans and doesn't turn them on unless it really needs to. It can get quite hot before it needs to. I don't hear it, but them I do have five disks in my HTPC, so I hear a very slight noise from them when a few spin up.
-
Yeah, I see you have quite a few drives there, but the reds are fairly quiet.
My primary concern at build was audio (I fell into video later) so I went to considerable trouble to make the machine as quiet as possible. I have a passively cooled graphics card and everything. But that's harder to do now than it used to be; the current crop of cards are too hot. I'm not aware of anyone selling a passively cooled current gen card. Anyway you can't hear the thing unless you put your ear within about 12 inches of it, so it turned out pretty near silent.
I have elsewhere a totally passively cooled Zotac Zbox (Core i5) that is absolutely silent so that is great for audio, but doesn't have the horsepower for MadVR.
I've found the scaler in my LG to be excellent, but it obviously varies by make. You're almost as far as I am... What size/brand is your TV?
-
What size/brand is your TV?
It's a 65" Sony, KD-65X9300D. The Australian version of the American XBR-65X930D I believe. The last of their 3D capable TVs.
-
Ah, so you're in the same situation as me. I have the LG 65EF9500, the first of the flat screen OLEDs. But we're both 65in and too far away to see 4K. The Sonys have very good scalers too I think.
-
Guys, you won't believe, but I have an interesting update :D
As you know, I've returned the Intel NUC to the seller. He told me it was likely that the drivers weren't quite functional yet with this new type of hardware. Yeah, I found that out aswell...
Anyway, today I decided to give my old HTPC a final chance to make up. So, I installed Windows 10 Pro (which didn't work properly for my hardware in the past), got a graphics + display audio driver update from Intel when I installed the Intel Driver Support Assistant and.... everything works again!!
Also, no need to set for a 2 seconds delay when changing framerates, no need to set 1 sec delay when playing audio. So it wasn't my Anthem that was slow but the NUC.
16-44.1, 24-88.1 & 24-176.4 play using Wasapi, multi-channel or stereo, the lot, no questions asked!
I'm happy. I think I'll stick with my good old companion for a while :-) Thanks again for all your help, but this couldn't be solved as it was imho a matter of disfunctional drivers for the hardware.
-
Nice - but I still got get why your NUC has the issues but I've never seen it over my NUC (I've had about 5 so far)....
-
Was his model of NUC one you'd tried before, Jmone?
This honestly makes me a little leery of trying a NUC. I mean, 44.1KHz not working properly is just beyond the pale...
-
Mark has a NUC8, my latest one is a NUC7 so it could be that but.... I've never seen the issue on my NUCs (or even the ComputeSticks).
-
Mark has a NUC8, my latest one is a NUC7 so it could be that but.... I've never seen the issue on my NUCs (or even the ComputeSticks).
Hi Jmone, you did test the NUC8i5BEK, right? That's practically the same as my NUC8i5BEH
-
Well my bad!!!!, I saw WER's post in my NUC7 review and used that for the testing in the thread!
Yes I do have a NUC8i5BEK and just had a quick look. There are issues for me. Everything played except for 176/24, well it played but there was no sound (the AVR also reported it as receiving the audio at the correct format but.... no sound). In digging further this NUC was set to "Source # of Channels in the DSP". When I changed MC to JRSS 5.1, then 44.1 / 88.2 / 176 @ 24-Bits would play but again, there was no sound.
It's also on Windows 1803 and last years intel drivers, so I've started the round of doing SW & Driver Updates and well report back.
Mmmm I wonder if it is bitrate thing on 44.1/88.2/176 @ 24bits, as:
- 2ch 44.1 and 88.2 plays fine
- 2ch 176 plays but without sound or error
- 5.1ch 44.1 / 88.2 / 176 plays but without sound or error
-
This is really interesting to me, because as I mentioned earlier I've been considering a NUC myself...
As I recall, jmone, my post you referred to was basically begging you to give more comprehensive audio reviews (what works what doesn't) when you review a NUC.
Not to put too much burden on people like you and fitbrit, but with all the different machines you two build and test, it would be great if we could start building a list of PCs that are "certified for JRiver" that sort of thing. (Obviously JRiver also has the id, but since that is linux there are limitation.)
Not a real certification per se, but just "if you buy this NUC (or other SFF PC like a Zbox) and use these drivers, JRiver will be 100% fine, as tested by our forum experts" if you know what I mean.
Would have saved Mark here a lot of agony...
Mmmm I wonder if it is bitrate thing on 44.1/88.2/176 @ 24bits, as:
- 2ch 44.1 and 88.2 plays fine
- 2ch 176 plays but without sound or error
- 5.1ch 44.1 / 88.2 / 176 plays but without sound or error
I think this may be an important point. In the past, I have had problems playing some movies when output format=source # of channels, and the surround format for the movie was unusual. (I didn't get silence, I got the error message from MC about the sound card not liking the format). I solved this by telling MC to always output 7.1, and it just pads the empty channels with silence. The radeon card is happy, and zero compatibility issues since.
Your comment seems to indicate this solution wouldn't work on the NUC, since it's not always playing sound in those channel counts. If you can't use source # of channels, and you can't force everything to 7.1 (or whatever your needed max is) then you're basically screwed.
Jmone, could you please test the following?
-48khz (16 and 24 bit) at 1.0, 2.0, 3.0, 3.1/4.0, 5.1 and 7.1 (movie compatibility)
-16/24 at all sample rates up to 192 in 7.1
Seems like we're onto something here.
-Will
-
Hey Will, I've updated my reviews for what I've found on the NUC7 and 8. Please keep in mind that I'm just another MC user like you and unless I stumble upon an issue, it does not mean it is not there.
Anyway, here is what I found retesting the NUC7 and NUC8
NUC7i5BNH : No issues with the Audio
(https://yabb.jriver.com/interact/index.php?action=dlattach;topic=116703.0;attach=31966;image)
NUC8i5BEK : Tested the NUC's Audio Output using the Windows Sound System Properties and there are issues:
(https://yabb.jriver.com/interact/index.php?action=dlattach;topic=118012.0;attach=31968;image)
Not all combinations of Bitdepths, Sample Rates and Channel Counts worked over HDMI. The ones marked in Yellow would "Play" and the AVR would correctly report the details of the stream being received but there was no sound. Unless there is a fix or another workaround, you will need to use MC's DSP to sample unsupported Sample Rates, something like:
- 44.1 --> 48KHz
- 88.2 --> 96Khz
- 176.2 --> 192KHz
-
What I find odd - is that apart from this thread, I can find no other reports of the NUC8 with this issue....
-
Jmone, thanks so much, that is terrific work! (You might think of yourself as just another user, but most average users don't get to try so many different NUCs.)
And a very interesting result. I think fitbrit mentioned about them dropping support for some sample rates in newer drivers... I wonder if that also includes the multichannel scenarios here.
I can't recall if he named the "good" driver version, but I wonder if that would resolve what you're seeing here on the NUC8.
This is all amazingly valuable info for NUC owners or prospective NUC owners.
-
When you did those tests, were you using the same driver version on NUC7 and NUC8?
-
I can't recall if he named the "good" driver version, but I wonder if that would resolve what you're seeing here on the NUC8.
It is still possible to find posts about the "known good" driver that could be used when Intel dropped 192 KHz support, but I believe those drivers are too old now to worry about.
It would help if Intel included in their specifications what audio over HDMI is supported, but they seem to deliberately avoid doing that.
This looks like either a new bug in their code, or a deliberate reduction in support for whatever reasons they have.
I would love to use a NUC as a MC Client in my lounge room, and move the HTPC with all its disks to another location, or more likely host the MC Server on my Workstation, which would allow full and fast editing with all functions in MC (filenames, Views, etc.). Maybe with NAS storage under the house. But I'm not even going to try until this sort of thing is sorted out, and a NUC can support all video formats. Even then, I would have to give up 3D playback if I used a NUC client, which I don't wish to do.
As I have said elsewhere, I don't understand what Intel is thinking, causing all these issues. They don't seem to want to compete in the space. Or more correctly, they want to sell the gear, but don't tell anyone what it can do. You have to buy and experiment. At least we have Jmone to do that for us! 8)
Sorry. Whingy. But it is annoying.
-
On both the NUC7 and NUC8 I tried (from memory), the drivers I had from last year, then did the Windows / BIOS / Intel updates, then did the manual Intel GFX Update. I did not notice any difference, eg the NUC7 always worked, and the NUC8 always had the issue.
That said, how big of a crime is it to have MC resample 44.1 --> 48, 88.2 --> 96, and 176 --> 192? I personally would be OK with that and it sidesteps the issue altogether.
The other thing is the NUCs IGX are still compromised for UHD Playback as they are pretty weak. The NUC8 or OK for std UHD but not for UHD@High Frame Rates (eg anything like 50/60fps you could get from a camera)... so if you want the best you really need a dedicated GPU but then the size of the box and $$$ jump.
There is a new NUC8i5INHX coming out with an AMD GPU... maybe this will be better.
-
I'm thinking it has to be a bug (driver or chipset?), as you can Select these combinations and they do work in that the player will output it, and the AVR will report it has the stream but it is just Silent. That said I do notice that the Windows Sound System Properties seems to know somthing is up as when you press "Test" it never finished, you have to press "Stop".
Still has me confused why no one else in the WWW is reporting it.
-
That said, how big of a crime is it to have MC resample 44.1 --> 48, 88.2 --> 96, and 176 --> 192? I personally would be OK with that and it sidesteps the issue altogether.
I would call it a low-grade felony.
If you want to upsample, you should be upsampling to an integer multiple; if you don't every sample gets interpolated. With the loss of 88 and 176, it becomes impossible to integer upsample 44.1, if you have to force a multichannel output format for movie compatibility, or if you are using JRSS or duplicating channels for "quadraphonic" stereo.
Also, as Roderick points out, this is an unforced error on Intel's part. The hardware supports 88 and 176 as shown by 2-channel playback, and has the bandwidth because it does 7.1 192.
There's no excuse for this kind of foul-up.
I can forgive not being able to cram great 4k performance into such a small package. But audio should be a slam dunk.
-
That said, how big of a crime is it to have MC resample 44.1 --> 48, 88.2 --> 96, and 176 --> 192? I personally would be OK with that and it sidesteps the issue altogether.
Until the next driver that loses some other capability. Users are continually chasing a moving target. With no documentation of expected capability, just generic specifications. Plus no admission of a problem in previous cases.
But audio should be a slam dunk.
This.
-
I tried to create a thread on the Intel NUC Support Forum - https://forums.intel.com/s/topic/0TO0P00000018NQWAY/intel-nucs?language=en_US to see what they say.... but while I could create an account but when I login, it kept taking back to a landing page. Rinse and Repeat. Maybe someone else can see if they can post over there as I don't think we will get much further on our own.
Also In the interim (and I get the argument about upsaming to non integer multiple).... but can you actually hear any difference (I can not but .... others may).
-
You didn't happen to name that post "NUC8i7BEH Sound Issue...yes, again with this qu..." did you? Actually, no you probably didn't, as it is dated October 2018.
https://communities.intel.com/thread/129582
I found that thread in Google, but when I try to view it Intel insists I log in or create an account? What? Since when couldn't you view the Intel Communities pages without logging in?
Might try to create an account.
-
Not me. But I now can not get to any post in their forum, the redirect link that they use fails.... Oh Well, I'll try later.
-
So I created an account with Intel. Tried my link above. Error. Search for the title. Not found. Tried your link Jmone. Just gives a generic list of threads.
This is why you aren't seeing issues on the www. Intel seems to be actively hiding them. But Google still finds them. Sigh.
I don't feel I can ask a question in the communities as I don't have a NUC. I can't answer the questions they will have.
I couldn't find anything sensible in the community either.
-
Well my bad!!!!, I saw WER's post in my NUC7 review and used that for the testing in the thread!
Yes I do have a NUC8i5BEK and just had a quick look. There are issues for me. Everything played except for 176/24, well it played but there was no sound (the AVR also reported it as receiving the audio at the correct format but.... no sound). In digging further this NUC was set to "Source # of Channels in the DSP". When I changed MC to JRSS 5.1, then 44.1 / 88.2 / 176 @ 24-Bits would play but again, there was no sound.
It's also on Windows 1803 and last years intel drivers, so I've started the round of doing SW & Driver Updates and well report back.
Mmmm I wonder if it is bitrate thing on 44.1/88.2/176 @ 24bits, as:
- 2ch 44.1 and 88.2 plays fine
- 2ch 176 plays but without sound or error
- 5.1ch 44.1 / 88.2 / 176 plays but without sound or error
Ah, I'm not alone... Not that I'm happy so to see this but now we can probably safely state it's not a matter lack of computerskills on my behalf :-) Anyway, in my case, it didn't matter if the bitrate was 16 or 24, nor if it was stereo or multi-channel. Just no sound when playing 44.1, 88.2 & 176.4.
-
Not to put too much burden on people like you and fitbrit, but with all the different machines you two build and test, it would be great if we could start building a list of PCs that are "certified for JRiver" that sort of thing. (Obviously JRiver also has the id, but since that is linux there are limitation.)
Not a real certification per se, but just "if you buy this NUC (or other SFF PC like a Zbox) and use these drivers, JRiver will be 100% fine, as tested by our forum experts" if you know what I mean.
That's what I was thinking about too! In the Netherlands, where I live, there is site called hardware.info. Every now and then they publish an advised setup for various goals, like gaming, video-editing etc. Check this: https://nl.hardware.info/pcadvies/1137/budget-all-round-pc---januari-2019. I've followed their advice twice for my allround desktop, and to much satisfaction.
It would be great if JRiver could do something similar for building a HTPC. For instance:
1. entry level HTPC, which plays audio fine + Red October Standard;
2. high-end 4K Red October HQ with MadVR set to max, HDR10 support etc etc.
And whichever other combinations in between might be relevant. Maybe set to categories < 500, 500- 1000, 1000+ in $? Advice would be nice on which motherboard (Realtek or Intel audio....), onboard gpu, how much RAM, which power supply (Be Quiet?), which casing, which GPU and/or soundcard if you want a dedicated one, cables, connectivity etc etc.
I hope to see this on the board someday, as it might really help a lot of people as it is rather specific knowledge. It would certainly help as I probably would like to upgrade my HTPC within the next year.
-
It is still possible to find posts about the "known good" driver that could be used when Intel dropped 192 KHz support, but I believe those drivers are too old now to worry about.
It would help if Intel included in their specifications what audio over HDMI is supported, but they seem to deliberately avoid doing that.
This looks like either a new bug in their code, or a deliberate reduction in support for whatever reasons they have.
I would love to use a NUC as a MC Client in my lounge room, and move the HTPC with all its disks to another location, or more likely host the MC Server on my Workstation, which would allow full and fast editing with all functions in MC (filenames, Views, etc.). Maybe with NAS storage under the house. But I'm not even going to try until this sort of thing is sorted out, and a NUC can support all video formats. Even then, I would have to give up 3D playback if I used a NUC client, which I don't wish to do.
As I have said elsewhere, I don't understand what Intel is thinking, causing all these issues. They don't seem to want to compete in the space. Or more correctly, they want to sell the gear, but don't tell anyone what it can do. You have to buy and experiment. At least we have Jmone to do that for us! 8)
Sorry. Whingy. But it is annoying.
Something else the seller of my NUC told me was that since the NUC's are rather cheap, there are compromises. They don't spend too much development cost on it to keep prices rather low. And that means the NUC in my case wasn't quite ready to put on the market as the drivers didn't work with the new hardware. At least not for use as an HTPC. Also, I found it was rather loud when the CPU was doing a lot of work. Once I thought I had a drone in my living room but it was the NUC doing it's job. Fortunalety it was connected by HDMI otherwise it would have disappeared....
-
Until the next driver that loses some other capability. Users are continually chasing a moving target. With no documentation of expected capability, just generic specifications. Plus no admission of a problem in previous cases.
Exactly the reason for me returning the NUC. I simply have no faith in it anymore, I can't rely on it. Also the reason why my next HTPC won't have Intel audio. It's a miracle my old HTPC works flawlessly now on Windows 10 Pro as last year it didn't work properly when I tried. For instance, I had to have the TV on to play audio. Now that's not necessary any more. Also, I've seen a lot of extra problems concerning Intel audio. And in much occasions it was a faulty driver. Some people switched to Microsoft HD audio device and other drivers to get it working, but for me that didn't work either. IMHO, Realtek seems to the best alternative now. Or a dedicated soundcard if there's one (something for the JRiver advised HTPC?) that functions over HDMI. Intel is not something you can rely on anymore. But that's just me...
-
I agree, and that's why I have held off buying a NUC.
Audio over HDMI makes so much sense, with the connection from PC > AVR > TV, but it just doesn't seem reliable with all hardware and driver configurations. Not just Intel iGPU based HDMI either.
It seems that audio via USB, which means two output cables from a PC, and potential synchronisation issues, is currently the best solution.
-
I've used HDMI a lot and not seen many problems. I think this one may just be an Intel driver problem. I reported it to our contact at Intel.
-
Thanks Jim. I'll be interested in what they say as I've not seen this issue before.
FYI - Over the years I've seens lots of issue but it is usually around EDID or HDCP components and used to purchase stuff the HDMI Detective. These issues (for me) are mostly gone these days.
-
Audio over HDMI makes so much sense, with the connection from PC > AVR > TV, but it just doesn't seem reliable with all hardware and driver configurations. Not just Intel iGPU based HDMI either.
HDMI is far from a perfect solution. It came to us pre-crippled thanks to HDCP, and is plagued by handshaking issues from multiple vendors. And of course the auto lip sync functionality has never worked.
But I think it is the least of a variety of evils. Interfaces that are more capable, like MADI, are not widespread enough to be useful to regular consumers. Reliable interfaces, like S/PDIF don't have the needed capabilities. Best to just try and find a working HDMI implementation.
My experience exactly mirrors jmone's. This is a very unusual situation, but one of Intel's making.
People should stick with the NUC7 if they want it to work, I guess...
-
Just received this reply from Intel:
As promised here are those resources for you and your team to utilize as an initial solution to troubleshoot the audio issues that were encountered. Should the issue persist, you can open a ticket with the Intel Support Team and if you provide me with the ticket number I can ensure you receive adequate support.
When you’re ready to roll out your next project endeavor please give me a call, I’d love to help.
In the meantime, please let me know if there is anything else I can do for you!
NUC driver downloads (HD Audio Driver and HD Graphics Driver are recommended): https://downloadcenter.intel.com/product/126147/Intel-NUC-Kit-NUC8i5BEK
Intel Support (open technical support ticket here): https://www.intel.com/content/www/us/en/my-intel/support-sign-in.html?redirect=https://sfederation.intel.com/federation/Init_Salesforce_ISVC.asp?RelayState=/supportrequest?lang=en-US%26productId=98414:9958
HDMI Audio Troubleshoot (addtl resource that may be helpful) - https://www.intel.com/content/www/us/en/support/articles/000006796.html?productId=129701&localeCode=us_en
-
Nice resource, Jim.
Can you change the thread title to "NUC8 Audio & video problems" so people can find it?
-
Intel Support (open technical support ticket here): https://www.intel.com/content/www/us/en/my-intel/support-sign-in.html?redirect=https://sfederation.intel.com/federation/Init_Salesforce_ISVC.asp?RelayState=/supportrequest?lang=en-US%26productId=98414:9958
FYI - I still get the same issue tying to raise a ticked from this link as well
The requested URL was rejected. Please consult with your administrator.
Your support ID is: 5904129979193534176
I also retested (as there was a newer Realtek Driver). No change.