[pvrusb2] Noise

[Diego Rivera]

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 <jan.ceuleers at computer.org>
> Date: 4/21/19  8:21 AM  (GMT-06:00) To: pvrusb2 at isely.net 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, isely at isely.net
> 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>> pvrusb2 at isely.net>> 
> http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2>>_______________________________________________pvrusb2
> mailing listpvrusb2 at isely.net
> http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2_______________________________________________pvrusb2
> mailing listpvrusb2 at isely.net
> http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
-- 



Diego Rivera

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <http://www.isely.net/pipermail/pvrusb2/attachments/20190421/2d2cbf7c/attachment.sig>