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 <[email protected]> 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@rasptune ~# rmmod pvrusb2 > root@rasptune ~# modprobe pvrusb2 debug=1 > (waiting a moment for RF tracking filter calibration...) > root@rasptune ~# cd /sys/class/pvrusb2/sn-7836611 > root@rasptune:/sys/class/pvrusb2/sn-7836611# echo "PAL-Nc" > > ctl_video_standard_mask_active/cur_val > root@rasptune:/sys/class/pvrusb2/sn-7836611# v4l2-ctl --set-freq 163.25 > Frequency set to 2612 (163.250000 MHz) > root@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@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 _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
