[pvrusb2] Hauppauge HVR-1900 - PAL-Nc, no audio
Mike Isely
isely at isely.net
Thu Apr 11 22:59:09 CDT 2013
Multiple additional comments interspersed below...
On Mon, 8 Apr 2013, Dermot Buckley wrote:
> Hi Mike,
>
> Thanks for the response.
>
> On 8 Apr 2013, at 11:43, Mike Isely <isely at isely.net> wrote:
> > In times past when I've dealt with bugs involving "no captured audio",
> > the usual suspect was that the pvrusb2 hardware was being told to use
> > the wrong broadcast standard. It's possible to choose a standard that
> > is "close enough" for, say, video to work but not audio. There are
> > different modulation standards and frequencies for the embedded audio
> > and if that is set wrong, then of course there will be no audio.
> >
> > Making matters somewhat more confusing is that in many cases, the
> > hardware can successfully guess the correct audio configuration even
> > when the wrong standard is set. So you can get cases where, for
> > example, someone with a 24xxx series device will get working audio using
> > standard "XYZ" while someone else in the same country but using a 29xxx
> > device with the same "XYZ" standard still won't hear any audio :-(
>
> I'm about 98% certain of the broadcast standard I'm setting (PAL-Nc).
> Our regular TV (which is both NTSC- and PAL-capable) displays "PAL-N" and "SAP" when changing channels (not very technical I know!), and my testing (included below) would seem to point to PAL-Nc being the correct variation.
OK. I had to ask - because that's been a cause in the past...
>
> To verify, I checked all supported standards as follows:
>
> root at rasptune ~# rmmod pvrusb2
> root at rasptune ~# modprobe pvrusb2 debug=1
> (waiting a moment for RF tracking filter calibration...)
> root at rasptune ~# cd /sys/class/pvrusb2/sn-7836611
> root at rasptune:/sys/class/pvrusb2/sn-7836611# echo "PAL-Nc" > ctl_video_standard_mask_active/cur_val
> root at rasptune:/sys/class/pvrusb2/sn-7836611# v4l2-ctl --set-freq 163.25
> Frequency set to 2612 (163.250000 MHz)
> root at rasptune:/sys/class/pvrusb2/sn-7836611# v4l2-ctl --log-status
>
> Status Log:
>
> [ 9525.734707] pvrusb2: ================= START STATUS CARD #0 =================
> [ 9525.737103] cx25840 0-0044: Video signal: present
> [ 9525.737124] cx25840 0-0044: Detected format: PAL-Nc
> [ 9525.737137] cx25840 0-0044: Specified standard: automatic detection
> [ 9525.737165] cx25840 0-0044: Specified video input: Composite 7
> [ 9525.737180] cx25840 0-0044: Specified audioclock freq: 48000 Hz
> [ 9525.745622] cx25840 0-0044: Detected audio mode: forced mode
> [ 9525.745665] cx25840 0-0044: Detected audio standard: forced audio standard
> [ 9525.745680] cx25840 0-0044: Audio microcontroller: detecting
> [ 9525.745692] cx25840 0-0044: Configured audio standard: undefined
> [ 9525.745704] cx25840 0-0044: Configured audio mode: MONO1 (LANGUAGE A/Mono L+R channel for BTSC, EIAJ, A2)
This is interesting.
The cx25840 is what demodulates the audio from an analog signal. What
we see here strongly suggests that it isn't working properly. All 5 of
these lines look suspect (forced, still detecting, undefined standard,
mono audio mode). Unfortunately I can't guess as to why. If I were
directly seeing this here I'd probably be combing through the cx25840
module code in an attempt to see what generates those lines of output
and to trace back from that point. There may be debug trace you can
turn on in the cx25840 kernel module that may yield more clues as to how
it is getting into this state.
One thing is for sure - if the cx25840 hardware is not detecting audio
yet, then everything downstream of this point (and that's basically
everything) has no chance.
> [ 9525.745715] cx25840 0-0044: Specified audio input: Tuner (In8)
> [ 9525.745726] cx25840 0-0044: Preferred audio mode: stereo
> [ 9525.756834] cx25840 0-0044: IR Receiver:
> [ 9525.756866] cx25840 0-0044: Enabled: no
> [ 9525.756878] cx25840 0-0044: Demodulation from a carrier: disabled
> [ 9525.756887] cx25840 0-0044: FIFO: disabled
> [ 9525.756912] cx25840 0-0044: Pulse timers' start/stop trigger: disabled
> [ 9525.756924] cx25840 0-0044: FIFO data on pulse timer overflow: overflow marker
> [ 9525.756934] cx25840 0-0044: FIFO interrupt watermark: half full or greater
> [ 9525.756943] cx25840 0-0044: Loopback mode: normal receive
> [ 9525.756960] cx25840 0-0044: Max measurable pulse width: 318144512 us, 318144512000 ns
> [ 9525.756970] cx25840 0-0044: Low pass filter: disabled
> [ 9525.756979] cx25840 0-0044: Pulse width timer timed-out: no
> [ 9525.756988] cx25840 0-0044: Pulse width timer time-out intr: enabled
> [ 9525.756997] cx25840 0-0044: FIFO overrun: no
> [ 9525.757005] cx25840 0-0044: FIFO overrun interrupt: enabled
> [ 9525.757014] cx25840 0-0044: Busy: no
> [ 9525.757034] cx25840 0-0044: FIFO service requested: no
> [ 9525.757045] cx25840 0-0044: FIFO service request interrupt: enabled
> [ 9525.757054] cx25840 0-0044: IR Transmitter:
> [ 9525.757061] cx25840 0-0044: Enabled: no
> [ 9525.757070] cx25840 0-0044: Modulation onto a carrier: disabled
> [ 9525.757079] cx25840 0-0044: FIFO: disabled
> [ 9525.757088] cx25840 0-0044: FIFO interrupt watermark: half full or less
> [ 9525.757097] cx25840 0-0044: Carrier polarity: space:noburst mark:burst
> [ 9525.757110] cx25840 0-0044: Max pulse width: 318144512 us, 318144512000 ns
> [ 9525.757119] cx25840 0-0044: Busy: no
> [ 9525.757127] cx25840 0-0044: FIFO service requested: yes
> [ 9525.757135] cx25840 0-0044: FIFO service request interrupt: enabled
> [ 9525.757159] cx25840 0-0044: Brightness: 128
> [ 9525.757179] cx25840 0-0044: Contrast: 68
> [ 9525.757192] cx25840 0-0044: Saturation: 64
> [ 9525.757204] cx25840 0-0044: Hue: 0
> [ 9525.757215] cx25840 0-0044: Volume: 62225
> [ 9525.757227] cx25840 0-0044: Mute: false
> [ 9525.757238] cx25840 0-0044: Balance: 0
> [ 9525.757249] cx25840 0-0044: Bass: 0
> [ 9525.757259] cx25840 0-0044: Treble: 0
> [ 9525.757283] pvrusb2: cx2341x config:
> [ 9525.757299] pvrusb2: Stream: MPEG-2 Program Stream
> [ 9525.757314] pvrusb2: VBI Format: No VBI
> [ 9525.757327] pvrusb2: Video: 720x480, 30 fps
> [ 9525.757342] pvrusb2: Video: MPEG-2, 4x3, Variable Bitrate, 6000000, Peak 8000000
> [ 9525.757359] pvrusb2: Video: GOP Size 12, 2 B-Frames, GOP Closure
> [ 9525.757376] pvrusb2: Audio: 48 kHz, MPEG-1/2 Layer II, 224 kbps, Stereo, No Emphasis, No CRC
> [ 9525.757399] pvrusb2: Spatial Filter: Manual, Luma 1D Horizontal, Chroma 1D Horizontal, 0
> [ 9525.757425] pvrusb2: Temporal Filter: Manual, 8
> [ 9525.757440] pvrusb2: Median Filter: Off, Luma [0, 255], Chroma [0, 255]
> [ 9525.757458] pvrusb2_a driver: <ok> <init> <connected> <mode=analog>
> [ 9525.757473] pvrusb2_a pipeline: <idle> <configok>
> [ 9525.757490] pvrusb2_a worker: <decode:quiescent> <encode:virgin> <encode:waitok> <usb:stop> <pathway:ok>
> [ 9525.757501] pvrusb2_a state: ready
> [ 9525.757522] pvrusb2_a Hardware supported inputs: television, dtv, composite, s-video; allowed inputs: television, composite, s-video
> [ 9525.757553] pvrusb2_a Bytes streamed=0 URBs: queued=0 idle=0 ready=0 processed=0 failed=0
> [ 9525.757566] pvrusb2_a ir scheme: id=2 Zilog
> [ 9525.757587] pvrusb2_a Associated v4l2-subdev drivers and I2C clients:
> [ 9525.757596] pvrusb2_a cx25840: cx25840 @ 44
> [ 9525.757605] pvrusb2_a tuner: tuner @ 42
> [ 9525.757614] pvrusb2: ================== END STATUS CARD #0 ==================
> root at rasptune:/sys/class/pvrusb2/sn-7836611# for std in $(cat ctl_video_standard_mask_available/cur_val); \
> do echo $std; echo $std > ctl_video_standard_mask_active/cur_val; \
> timeout 10 cat /dev/video0 > /home/pi/test_$std.mpg; \
> done
> PAL-B
> PAL-B1
> PAL-G
> PAL-H
> PAL-I
> PAL-D
> PAL-D1
> PAL-K
> PAL-N
> PAL-Nc
> SECAM-B
> SECAM-D
> SECAM-G
> SECAM-H
> SECAM-K
> SECAM-K1
> SECAM-L
> SECAM-LC
> ATSC-8VSB
> ATSC-16VSB
>
> I've uploaded all the generated mpegs to http://bone.buckleycomputers.ie/hvr1900pvrusb2/
> The only one with valid video is test_PAL-Nc.mpg. All are silent (but there is a very slight static in PAL-G, PAL-L, SECAM-G, and SECAM-LC).
>
> >
> > The pvrusb2 driver does not directly program the audio configuration in
> > the capture device. That job is left to the various chip drivers, e.g.
> > cx25840.ko in your case. What the pvrusb2 driver does do however is to
> > communicate the chosen standard out to the various chip drivers; then it
> > is up to each chip driver to use that information to create the
> > appropriate local configuration in the hardware.
>
> Do you know if there's a way I can force the cx25840 to use a
> particular standard? Looking through cx25840-core.c, there aren't
> very many of them - it'd be worth trying them all if I knew how.
Well the pvrusb2 driver should be *telling* cx25840 what to use. By
changing it at the pvrusb2 level, the driver should be tracking with it.
I know there's debug trace that can be turned on in the cx25840 kernel
module (try "modinfo cx25840"). That should give some more clues.
>
> Also, one very specific question: In pvrusb2-hdw.c a comment mentions that:
>
> // Enable PAL-N for PAL-capable devices. One user in
> // Argentina has encountered this.
>
> Assuming that this is *your* comment - does this mean that someone
> else has broken this ground before? Do you know if they were
> successful?
Yes, that is my comment, from long ago. The backstory is basically
this:
The hauppauge EEPROM contains additional data that the host driver
(pvrusb2 in this case) can use to adjust its behavior. There's a module
called "tveeprom" that decodes this data and makes it available. Among
the contents is included a list of video standards that the hardware is
supposed to support. This list may vary, depending on country where you
purchased the device. Way back in the early days I actually did a
census to figure out how many different variants were in circulation
around the world.
Well the reality is that the device might report supporting a particular
subset of video standards, but the *actual* set of standards that the
hardware can support may actually be much wider. In fact with more
recent HVR-xxxx devices it's entirely possible that they can support
nearly every standard in the same silicon. The pvrusb2 driver
originally just dutifully used this 'supported' list to limit what the
TV application could choose. When I realized the situation that the
hardware could do better, I added logic to the pvrusb2 driver that
attempted to detect the particular variant and to expand the 'supported'
list accordingly.
The comment you found was due to a user encountering this scenario - he
had a device in use in a country where the EEPROM-report 'support' list
didn't include his regional video standard but we both realized that the
hardware could handle it. So I added code to include his situation.
This was all quite some time ago (many years ago). IIRC, there's a way
in the sysfs interface to forcibly expand the 'supported' list to
basically whatever you want. But I don't think this is going to help
you because it appears that you've already selected what should be the
correct standard. Of course you're free to experiment.
I think the most productive next step might be to turn on trace print in
the cx25840 kernel module in an attempt to figure out how it is getting
into that suspect state.
>
> Once again, appreciate any help you can offer.
Sorry for the reply delay. It has been a crazy week for me (and there's
another equally crazy week to follow). I wish I could help you more.
-Mike
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
More information about the pvrusb2
mailing list