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 > -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
