Choppy Audio Due to Possible Incorrect Filter Graph

[PVRDon]

I installed nPVR last week and it is now working just about 100%. I am using an HDHomeRUN dual tuner device and a Mohu Leaf antenna for the TV signal source.

The video and audio on the HD TV channels are superb, and often better than cable.

But - I have one small problem: choppy audio on a few of the non-HD channels when watching live TV. These channels show between 95 and 100 percent signal strength (3 green bars using the HDHomeRun Config GUI software) while the problem is ocurring.

After some trial and error, I believe the problem is that nPVR is creating a filter graph that may be incorrect, i.e., it is connecting the MPEG1 audio pins in addition to the AC3 pins, when only the AC3 pins are needed.

When I disable the MPEG1 audio decoder in the Decoders section of the Settings panel, the problem goes away. All of the channels continue to output audio, and the problem channels now have clear audio. However, this also disables the audio in some of my videos, so this method of fixing the problem is not a permanent solution.

Changing the MPEG1 decoder and the AC3 decoder to a different decoder does not fix the problem or change the behavior. The new decoders are used by nPVR, and both the MPEG1 pins and the AC3 pins are connected.

A Grafedit filter graph display shows the described behavior, as does the nPVR log file, which indicates that the MPEG1 decoder and renderer are being used, along with the AC3 decoder and renderer.

I have attached my config.xml file, along with the log file of the live TV session which exhibits the problem. I will also attempt to attach the filter graph screen print.

NPVR is an amazing piece of software. I would like to fix this problem, if possible, and use it for viewing live TV.

Any help would be greatly appreciated. Thanks in advance for any suggestions you may have.

Donald

[mvallevand]

I have this registry setting in the NPVR Registry

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\NPVR]
"PreferAC3"=dword:00000001

and it makes all the difference. If you don't have mpeg2 analog recordings you can probably leave mpeg2 audio disabled.

Martin

[PVRDon]

Martin,

Thank you for your reply.

But, why should I have to edit the registry to have nPVR construct a correct filter graph?
There is no MPEG1/2 audio being received on any of my TV channels. Is the type of input audio not available to nPVR when live TV is selected?

Some of my older videos have MPEG1/2 audio.

Donald

P.S. I installed the registry key and there was no change to nPVR's behavior with respect to the filter graph and no change to the problem. I can still disable the MPEG1/2 decoder and the problem goes away.
I will be removing the registry key.

[mvallevand]

For speed reasons in live tv sub choose to not determine the file's real characteristics and instead builds the graph for the worst case with all decoders.

Martin

[johnsonx42]

yes, I've found the PreferAC3=1 registry doesn't help at all for this. Martin's situation is different somehow, or he's solving a different problem.

unfortunately I've found nothing that will make both AC3 and MPEG1 audio channels work correctly at the same time. The best I've been able to do is make AC3 audio work correctly, and figure I just don't watch live on MPEG1 channels. To do this, edit config.xml and set <ForcedLiveTVClock>AC3 Audio Renderer</ForcedLiveTVClock> (it's in the <Renderers> section).

Apparently the problem boils down to Windows not doing what it's supposed to do. NPVR is correctly asking Windows to set the clock source once each channel is tuned and the audio stream is detected, but Windows just isn't doing it. It sticks with the clock reference set when the graph was first built, which is governed by the <ForcedLiveTVClock> setting.

[sub]

For speed reasons in live tv sub choose to not determine the file's real characteristics and instead builds the graph for the worst case with all decoders.

When you play a recording, it does look at the real characteristics and adds only the decoders required.

When it comes to live tv though, it has to add all the audio decoders because it has no idea when type of audio it'll encounter. ie, even if you start on a channel AC3, it has no way to know that you're not going to switch to a channel with MPEG1 or AAC audio. For a lot of setups it's fine to have multiple audio decoders and renderers, and switch between them as required. For some users, this seems to lead to stuttering audio.

[PVRDon]

Thanks to all who took time out of their busy schedule to respond, especially sub.

Well, I guess there is at least one solution and two workarounds here:

1. Add a "Force AC3 on LiveTV" parameter to config.xml - please, please, please...
2. Record the show on the offending channel, then the filter issue and stuttering audio problem never arises - for reasons stated by sub ( it works - I have already tested this option)
3. Leave the MPEG1/2 decoder disabled and just don't use NextPVR to watch videos - or at least the older ones. Of course, this will always trip me up, because I will forget about disabling the decoder.

NextPVR is still the best PVR and media management solution for me - by far. Thanks again, sub.

Donald

[sub]

1. Add a "Force AC3 on LiveTV" parameter to config.xml - please, please, please...

Sorry, I don't follow you. What do you mean? As Johnsonx42 mentioned above, there is already a config.xml entry to force it to use the AC3 clock in Live TV.

Do any of you ATSC guys have a frequency that happens to have both an HD channel with AC3 and a SD channel with MPEG1? I don't have anything like this in New Zealand, which might contribute to me not seeing the problem. If you can supply a sample file, I'll try it here with my ATSC signal generator to try again to reproduce it.

[mvallevand]

Here SD over QAM and ATSC is still AC3.

Martin

[sub]

It is a valid option for ATSC, so there may be some users that have access to this combination of broadcast.