Interesting question: which firmware version are you using (and how big is it in bytes)? There are several versions floating about out there, and I know only one is the "latest and correctest" one. Perhaps in your travails of O/S upgrades over the years you've mistakenly installed the wrong one? Cheers...
On Sun, 2019-04-21 at 08:55 -0500, Mike Isely wrote: > The pvrusb2 driver is supposed to select the audio input in conjunction with > the video choice. > There is a map in the driver that, based upon the particular model, should be > selecting the > correct audio input for you when you select the "overall" input. It has > always been like that. If > there's a problem there now with that, well, it is another thing that needs > to be > investigated.More stuff to dig out, with no extra time in which to do it > :-(Sent from my T-Mobile > 4G LTE Device-------- Original message --------From: Jan Ceuleers > <[email protected]> > Date: 4/21/19 8:21 AM (GMT-06:00) To: [email protected] Subject: Re: > [pvrusb2] Noise Mike,Thanks > for your reply.Given that in the past it was possible (in fact necessary) to > select theaudio input > and that this is no longer possible/necessary now, am Iright in thinking that > the driver programs > the hardware to add all audiosources together on the assumption that only the > "correct"-one > willactually be producing an audio signal and the others will be silent?If > so, are there > circumstances under which this assumption might be false?Again if so, is > there anything I can do > about that? For example, in myuse case (where I'm only recording from line in > and composite video > in)can I disable certain components that aren't being used? For example > getrid of certain firmware > images, or use certain pvrusb2 module parameters?Thanks, JanOn 21/04/2019 > 14:54, [email protected] > wrote:> Jan:>> That's an odd symptom. Getting audio from an RF signal > actually has a > longer > processing path than audio from the line-in port. In fact, > there should be > very little (if > anything) involved with the line-in port > that isn't also involved with > processing audio from an > RF signal. In > either of those two cases, the audio is processed by a > separate chip > (cx25840 > IIRC) and the result of that is what is fed into the mpeg > encoder chip. > Once past the cx25840, > there's no difference in the > datapath.>> There's a separate driver for the > cx25840, which the > pvrusb2 driver > employs, which is part of the v4l2 subsystem as a whole, so > any problem > > involving audio like you describe should also be likely with any other > > video capture driver that > also happens to use a cx25840. I know this > isn't being very helpful, but > it does suggest that > looking for other > online chatter involving that part might reveal another > clue.>> -Mike>>> On > Sun, 21 Apr 2019, Jan Ceuleers wrote:>>> Dear list,>>>> I am seeking some > help with an audio > defect that afflicts some>> recordings made using Hauppauge PVR 1950 > devices.>>>> I have two > mythtv backends:>>>> - the slave backend has three 1950s that record from > analogue cable.>> Audio > recorded from these tuners is fine.>>>> - the master backend has two 1950 > PVRs that record from > set-top boxes>> (i.e. from the composite video input and line audio inputs). > All>> recordings made > using these two tuners suffer from an audio defect as>> described below.>>>> > The audio defect is a > clearly audible repetitive "whistling" noise, with>> a periodicity of about 1 > second. This noise > is not present on the audio>> signal that goes into the PVR.>>>> I have tried > many variations of > v4l2-ctl -d$device -f $freq without>> effect (and have settled on 450 MHz as > the frequency). The > point of>> doing this is that I want to exclude noise from the channel the > analogue>> tuner > happens to be tuned to.>>>> Many moons ago a pvrusb2 device had multiple > audio inputs from which > one>> could select the right-one using v4l2-ctl -d$device>> > --set-audio-input=$audiodev , with > valid values for audiodev being 0, 1>> and 2. The correct setting for my use > case was 1. This is > no longer the>> case: the device presents only one audio input which is > numbered 0.>>>> I'd be > grateful for any hints.>>>> Thanks, Jan>>>> > _______________________________________________>> > pvrusb2 mailing list>> [email protected]>> > http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2>>_______________________________________________pvrusb2 > mailing [email protected] > http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2_______________________________________________pvrusb2 > mailing [email protected] > http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2 -- Diego Rivera
signature.asc
Description: This is a digitally signed message part
_______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
