Re: cx18: missing audio for analog recordings
On 17/04/10 12:43 AM, Andy Walls wrote: I had to disassemble and study some of the microcontorller firmware, and then reread some documents, to figure out how all the audio detection resets must work. I've just pushed some microcontroller reset related changes to the cx18-audio2 repo. Please test and see if things are better or worse. .. Mmm.. something is not right -- the audio is failing constantly with that change. Perhaps if I could dump out the registers, we might see what is wrong. I also tried: v4l2-dbg -d /dev/video1 -c type=host,chip=1 --list-registers=min=0x800,max=0x9ff but that fails to read any of the registers (ioctl: VIDIOC_DBG_G_REGISTER failed for 0xXXX). I think I'll patch the driver to dump them for us. Thank-you for your work on this. There are many of us here hoping that we can figure out and fix whatever is wrong with our cards. Cheers -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On 16/04/10 08:59 AM, Andy Walls wrote: .. Accesses to those are orthognal to the rest of the cx18 driver, including the IRQ handler. (I agree, its hard to follow things in the driver; it's very large.) Do note, however, that the audio standard detection microcontroller *does* write to the registers in 0x800-0x9ff *independent* of the linux cx18 driver. Locking with respect to the microcontroller would mean halting and restarting the microcontroller. I don't know if that causes it to reset or not, and I do not know how it affects it's internal timers. .. Since the problem really does behave like a race condition would behave, I wonder if it could have something to do with how/when we modify any of those registers which are shared with the microcontroller? The cx18 driver *always* does read-modify-write (RMW) of 32-bits at at time, even when just an 8-bit register is being modified. If the microcontroller is using/updating the other 24-bits of any of those registers, then the cx18 driver's RMW will destroy values that the microcontroller has written. Is it possible to write only 8-bits, rather than having to do the RMW on 32-bits ? Cheers -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On 17/04/10 08:09 AM, Mark Lord wrote: .. Mmm.. something is not right -- the audio is failing constantly with that change. Perhaps if I could dump out the registers, we might see what is wrong. .. When the microcontroller is reset, does it put all settings back to defaults? I wonder if this causes it to select a different audio input, as part of the reset? If so, then we'll need to reselect the tuner-audio afterward. Anything else? ?? -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On Sat, 2010-04-17 at 08:09 -0400, Mark Lord wrote: On 17/04/10 12:43 AM, Andy Walls wrote: I had to disassemble and study some of the microcontorller firmware, and then reread some documents, to figure out how all the audio detection resets must work. I've just pushed some microcontroller reset related changes to the cx18-audio2 repo. Please test and see if things are better or worse. .. Mmm.. something is not right -- the audio is failing constantly with that change. Crud. I added an additional soft reset using register 0x810 with that change; maybe that needs to be taken out. Perhaps if I could dump out the registers, we might see what is wrong. I also tried: v4l2-dbg -d /dev/video1 -c type=host,chip=1 --list-registers=min=0x800,max=0x9ff but that fails to read any of the registers (ioctl: VIDIOC_DBG_G_REGISTER failed for 0xXXX). I think I'll patch the driver to dump them for us. Whatever's easiest. As root, this should work: # v4l2-dbg -d /dev/video0 -c host1 --list-registers=min=0x800,max=0x9ff ioctl: VIDIOC_DBG_G_REGISTER 00 04 08 0C 10 14 18 1C 0800: 13248000 fefe 01010411 2000 80ff0200 20140905 31c0 478005d1 0820: 80002800 e084e044 007e54a8 240107f2 0186a020 24010800 0186a020 0840: 00801c00 0020 00a14f72 0030 7800 [...] 09c0: 80007ffc c000 0001 02000200 09e0: Or equivalently with the actual register addresses (vs. the logical remapping using host1): # v4l2-dbg -d /dev/video0 --list-registers=min=0x2c40800,max=0x2c409ff ioctl: VIDIOC_DBG_G_REGISTER 00 04 08 0C 10 14 18 1C 02c40800: 137d8000 fefe 01010411 2000 80ff0200 20140905 31c0 478005d1 02c40820: 80002800 e084e044 007e54a8 240107f2 0186a020 24010800 0186a020 02c40840: 00801c00 0020 00a14f72 0030 7800 [...] 02c409c0: 7ffc27cc c000 0001 02000200 02c409e0: Dumps of registers might help me figure out something. Thank-you for your work on this. There are many of us here hoping that we can figure out and fix whatever is wrong with our cards. No problem. Sorry for all the shots in the dark so far. Without a BTSC/MTS signal source I'm just trying to guess what might be wrong. (Most VCR's, set top boxes, and RF modulators only seem to put out the monaural L+R sound signal and not an MTS BTSC signal with the pilot tone and stereo L-R as well). Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On Sat, 2010-04-17 at 09:01 -0400, Mark Lord wrote: On 17/04/10 08:09 AM, Mark Lord wrote: .. Mmm.. something is not right -- the audio is failing constantly with that change. Perhaps if I could dump out the registers, we might see what is wrong. .. When the microcontroller is reset, does it put all settings back to defaults? The microcontroller reset via register 0x803 causes the 8051 hardware to go to reset state and jump back to execute at address 0x of the loaded v4l-cx23418-dig.fw firmware image. I wonder if this causes it to select a different audio input, as part of the reset? The microcontroller doesn't control much in the way of routing except what outputs of the SIF decoding (L+R, L-R, SAP, dbx, NICAM) to route to the dematrix and the baseband audio processing path. If so, then we'll need to reselect the tuner-audio afterward. Anything else? I think the extra soft reset I added might be doing something bad. Based on what I can tell: 1. Register 0x803 start/stop of the microcontroller is for sure a microcontroller hardware reset and likely nothing else 2. Register 0x9cc bit 1 is almost certainly only a software flag to the microcontroller program. It doesn't appear to affect hardware. 3. Soft reset via register 0x810 must affect hardware units and registers and not the micrcontroller itself. So perhaps you could try removing the extra soft rest I added in my changes to cx18-av-core.c I also added a mute of baseband processing path 1 to the firmware load and init in cx18-av-firmware.c. The microcontroller should be unmuting things when it detects a broadcast standard, so I didn't think it was a problem. Maybe it is. Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On Sat, 2010-04-17 at 08:18 -0400, Mark Lord wrote: On 16/04/10 08:59 AM, Andy Walls wrote: .. Accesses to those are orthognal to the rest of the cx18 driver, including the IRQ handler. (I agree, its hard to follow things in the driver; it's very large.) Do note, however, that the audio standard detection microcontroller *does* write to the registers in 0x800-0x9ff *independent* of the linux cx18 driver. Locking with respect to the microcontroller would mean halting and restarting the microcontroller. I don't know if that causes it to reset or not, and I do not know how it affects it's internal timers. .. Since the problem really does behave like a race condition would behave, I wonder if it could have something to do with how/when we modify any of those registers which are shared with the microcontroller? It certainly could. The changes where we set our preferences in registers 0x808-0x80b need to be protected. We then need to notify the microcontroller properly that we have set things. Currently tmy latest changes do this: 1. halt the microcontroller by holding it in reset via register 0x803 (This is our lock out of the microcontroller from modifying registers) 2. assert the soft reset via register 0x810 3. set our preferences in register 0x808-0x80b 4. deassert soft reset via register 0x810 5. restart the microcontroller via register 0x803 6. Pulse the format detection reset flag via register 0x9cc 7. Schedule a 1.5 second delay to come back and check if the microcontroller found something. So I'm unsure about a. the exact sequencing of the current steps 2-4 (and if steps 2 4 are needed at all) b. if we're pulsing the bit in 0x9cc too rapidly in step 6 c. if we should wait a little longer than 1.5 seconds in step 7. The cx18 driver *always* does read-modify-write (RMW) of 32-bits at at time, even when just an 8-bit register is being modified. If the microcontroller is using/updating the other 24-bits of any of those registers, then the cx18 driver's RMW will destroy values that the microcontroller has written. The micrcontroller should only read registers 0x808-0x80b and never write them. I suspect the micrcontroller does check and modify the soft reset bit in register 0x810 itself at times. (I do not know what hardware units that bit resets, if any.) Register 0x9cc only ever appears to be read by the microcontroller. Is it possible to write only 8-bits, rather than having to do the RMW on 32-bits ? Yes it should be possible. PCI read of bytes are possible PCI bus transactions. I've never tried it, and there are no routines in cx18-io.[ch] presently to assist with the occasional failure to write a CX23418 register. You're welcome to check to se if it makes a difference, but please make sure you don't modify the firmware loading process, it's pretty touchy. Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On Thu, 2010-04-15 at 01:16 -0400, Mark Lord wrote: On 15/04/10 12:46 AM, Andy Walls wrote: On Wed, 2010-04-14 at 18:26 -0400, Mark Lord wrote: . Mmmm.. but it does do read-modify-write on several registers inside the IRQ handling. I suppose those might be safe groups, written to _only_ by the IRQ handler, but maybe not. In the linux driver, the registers in CX23418 address range: 0x2c4-0x2c409ff are only written to by the files named cx18-av-*[ch], which is mostly ioctl() call driven. (Those registers are logically mapped by the linux driver code to 0x000-0x9ff to make the integrated A/V decoder look like a CX25843 chip for convenience.) Accesses to those are orthognal to the rest of the cx18 driver, including the IRQ handler. (I agree, its hard to follow things in the driver; it's very large.) Do note, however, that the audio standard detection microcontroller *does* write to the registers in 0x800-0x9ff *independent* of the linux cx18 driver. Locking with respect to the microcontroller would mean halting and restarting the microcontroller. I don't know if that causes it to reset or not, and I do not know how it affects it's internal timers. Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On Wed, 2010-04-14 at 00:32 -0400, Mark Lord wrote: On 13/04/10 09:45 PM, Andy Walls wrote: The syslog shows the usual fallback messages, but the audio consisted of very loud static, the kind of noise one gets when the sample bits are all reversed. When in forced audio mode, the microcontroller will unmute. What you hear is what the decoder is decoding for BTSC. And that makes your observation *very* interesting. The sample rate conversion for SIF is fixed at about 62.937 ksps. That is 4 times the NTSC line rate of 15.734 kHz. Also note, that for anything other than simple monaural L+R audio, the BTSC subcarrier pilot and subcarrier center frequencies are based on multiples of Fh = 15.734 kHz. So if you hear something that sounds like sampling being performed at the wrong rate, I think we have one of two other problems: a. The horizontal sync tracking loop in the A/V decoder is way off (unlikely if you can see video properly) or b. the SIF signal from the analog tuner is off center. While it was failing, I tried retuning, stopping/starting the recording, etc.. nothing mattered. It wanted a reload of the cx18 driver to cure it. Since you have a unit with FM radio, for a simple test, when you notice the fallback happen: 1. stop your TV capture 2. perform a short FM radio capture with ivtv-radio (it doesn't have to find a station, it shouldn't matter) 3. retry your TV capture. I'm hoping that this reconfiguration of the analog tuner's IF demodulator chip will correct any problem with the SIF output from the analog tuner. Regards, Andy BTW, that's for all your testing. It's really helpful. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On Fri, 2010-04-16 at 09:15 -0400, Andy Walls wrote: Regards, Andy BTW, that's for all your testing. It's really helpful. ^^ That should be thanks. -Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On 15/04/10 01:16 AM, Mark Lord wrote: for now, I've added lower level spinlock protection onto all register writes, .. As you expected, this doesn't seem to have cured anything obvious. :) I had Mythtv wakeup/record/powerdown several times overnight, and it still required fallbacks for about half of those. And.. one of the fallback recordings still had muted audio. Even though my script which checks for that reported audio ok. Enough for now.. I'll hack some more on the weekend. cheers -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On 14/04/10 12:32 AM, Mark Lord wrote: .. The syslog shows the usual fallback messages, but the audio consisted of very loud static, the kind of noise one gets when the sample bits are all reversed. While it was failing, I tried retuning, stopping/starting the recording, etc.. nothing mattered. It wanted a reload of the cx18 driver to cure it. .. Since all of this happens rather randomly, I'm beginning to more strongly suspect a race condition somewhere in the driver. Now, it's a rather large driver -- lots of complexity in that chip -- so it will take me a while to sort through things. But at first blush, I don't see any obvious locking around the various read-modify-write sequences for the audio registers. And a quick grep spin *.[ch] shows a few spin_lock/spin_unlock calls in cx18-queue.c and cx18-stream.c (as well as the alsa code, which shouldn't be in play in this scenario). Oddly, none of those spinlocks use _irq or _irq_save/restore, which means they aren't providing any sort of mutual exclusion against the interrupt handler. But like I said, I'm only just beginning to look more closely now. -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On Wed, 2010-04-14 at 18:26 -0400, Mark Lord wrote: On 14/04/10 12:32 AM, Mark Lord wrote: .. The syslog shows the usual fallback messages, but the audio consisted of very loud static, the kind of noise one gets when the sample bits are all reversed. While it was failing, I tried retuning, stopping/starting the recording, etc.. nothing mattered. It wanted a reload of the cx18 driver to cure it. .. Since all of this happens rather randomly, I'm beginning to more strongly suspect a race condition somewhere in the driver. Now, it's a rather large driver -- lots of complexity in that chip -- so it will take me a while to sort through things. You can at least logically break it into components: cx18-av-* : the integrated A/V decoder subdevice (very much like a CX25843) cx18-gpio* : logical subdevices for functions controlled by GPIO cx18-alsa* : the ALSA interface presented to userspace cx18-fileops*, cx18-ioctl*, cx18-contorls* : The V4L2 interface cx18-dvb* : The DTV interface cx18-streams* : main streams management, and empty DMA buffer handover cx18-queue*: queue routines used for all queues for all streams cx18-mailbox*, cx18-scb* : driver-firmware API, main body of hard irq handler for incoming DMA, and workhandler for incoming DMA cx18-io* : Insanity to handle CX23418 PCI MMIO quirks cx18-irq* : The hard irq handler cx18-driver* : main driver probe and shutdown cx18-cards*: specifics on each supported card cx18-firmware* : Bridge and MPEG encoder firmware load and init, but not A/V core firmware cx18-i2c* : I2C master setup, bus driving, and device registration cx18-audio*: Top level audio routing functions cx18-video*: Top level video routing functions cx18-vbi* : VBI data extraction But at first blush, I don't see any obvious locking around the various read-modify-write sequences for the audio registers. The ioctl handling in the driver does it: $ grep serialize_lock * The serialize_lock is a bit overloaded, but it's frequent operational use is ioctl() serialization. The A/V core is almost exclusively manipulated by ioctl()s. The timer I added for fallback is an exception. And a quick grep spin *.[ch] shows a few spin_lock/spin_unlock calls in cx18-queue.c and cx18-stream.c (as well as the alsa code, which shouldn't be in play in this scenario). Correct. What is involved are the three reset processes in the cx18-av-* files: 1. Stopping and restarting the microcontroller via register 803 2. Soft reset (of what exactly?) via register 0x810 3. Format detection loop restart via register 0x9cc I have no idea if 2 3 above reset hardware and registers, or simply set a flag for the microcontroller firmware to notice, or both. So I've wondered about the exact sequencing of stopping the microcontoller, peforming the other 2 resets, and restarting the microcontroller. Oddly, none of those spinlocks use _irq or _irq_save/restore, which means they aren't providing any sort of mutual exclusion against the interrupt handler. There is no need. The hard irq handler only really deals with firmware mailbox ack and firmware mailbox ready notifications. It sucks off the mailbox contents and shoves it over to the cx18-NN-in workhandler via work orders placed on a workqueue. The work handler does grab the spinlocks, but it is from a non-irq context. But like I said, I'm only just beginning to look more closely now. Look at the publicly available CX25843 datasheet: http://dl.ivtvdriver.org/ pages 107-116 and Section 5.7. In figure 3.30 we've got SIF coming in from the analog tuner and the microcontoller is represented by the Auto Std/Mode Detection block. In figure 3-38 the output of the source select block is what then gets fed to the baseband processing chain as digital audio from the tuner. For reference, you may want to also grab FCC docment OET60 (Rev A from 1996?), which technically describes the BTSC audio subcarriers. Then Google for a nice pciture of the MTS/BTSC spectrum. This app note has a good picture in figure 1: http://assets.fluke.com/appnotes/it_products/Anbtsc.pdf although it is missing the PRO channel that is above SAP at 6fh IIRC. I don't know what part of the BTSC spectrum the Conexant microcontroller is keying off of, but I guessing the pilot for sure is part of the decision process. Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On 15/04/10 12:46 AM, Andy Walls wrote: On Wed, 2010-04-14 at 18:26 -0400, Mark Lord wrote: .. Oddly, none of those spinlocks use _irq or _irq_save/restore, which means they aren't providing any sort of mutual exclusion against the interrupt handler. There is no need. The hard irq handler only really deals with firmware mailbox ack and firmware mailbox ready notifications. It sucks off the mailbox contents and shoves it over to the cx18-NN-in workhandler via work orders placed on a workqueue. The work handler does grab the spinlocks, but it is from a non-irq context. .. Mmmm.. but it does do read-modify-write on several registers inside the IRQ handling. I suppose those might be safe groups, written to _only_ by the IRQ handler, but maybe not. From what I can see, (nearly?) all registers are read/written as full 32-bit units. So when code wants to modify an 8-bit register, this is converted into a read- modify-write of the corresponding 32-bit register. So if two threads, or any thread and the irq handler, want to modify parts of the same 32-bit register, then there's a race. The code _appears_ to mostly not have such a problem, but it would conveniently explain the sporadic failures. :) So, for now, I've added lower level spinlock protection onto all register writes, as well as to routines that themselves do a higher level read-modify-write: eg. the routines to enable/disable specific IRQ sources. This was easy enough to do, and it'll give us confidence that the r-m-w sequences are not the issue. Or perhaps it'll cure some problems. Time will tell. I'll run with that patch on top of yours for the next couple of days, or until I see a fallback log again. None so far, though. Cheers -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On Mon, 2010-04-12 at 22:34 -0400, Mark Lord wrote: On 12/04/10 10:30 PM, Mark Lord wrote: .. Mmm.. further to that: the problem went away as soon as I told it to tune to a different channel. No more fallbacks (for now). It can now even retune the original channel without fallbacks. So.. tuning to a new channel appears to fix whatever the bad state was that was triggering the fallbacks. Based on my sample of one, anyway. ;) .. Nope.. what that second email should have said, was Changing channels in LiveTV, no fallbacks required because the audio is already working from the initial fallback. As soon as I quit from LiveTV, the next recording still needed a new fallback. So the chip is still in some weird state where auto-audio will continue to fail until I reload the module. Thansk you for all the testing and feedback. At this point I'm going to brush up the fixes by properly incorporating support for the cx18_av_g_tuner()/cx18_av_s_tuner() calls so that user space can still influence the audio mode (mono, stereo, Lang1, lang2, etc.) even when audio standard and format are forced. I'll have time on Friday for this. The *only* other thing I can think of, that I have control over, is the PLL charge pump current in the analog tuner. Right now it is set to low current to minimize phase noise when tuned to a channel. Perhaps setting the PLL charge pump to high current while chaning the channel to get a faster lock, and low current after a short time, will help get a good SIF output from the analog tuner assembly sooner. Perhaps when I have time Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On 13/04/10 06:35 AM, Andy Walls wrote: On Mon, 2010-04-12 at 22:34 -0400, Mark Lord wrote: .. As soon as I quit from LiveTV, the next recording still needed a new fallback. So the chip is still in some weird state where auto-audio will continue to fail until I reload the module. .. The *only* other thing I can think of, that I have control over, is the PLL charge pump current in the analog tuner. Right now it is set to low current to minimize phase noise when tuned to a channel. Perhaps setting the PLL charge pump to high current while chaning the channel to get a faster lock, and low current after a short time, will help get a good SIF output from the analog tuner assembly sooner. Perhaps when I have time .. What's weird, is that things work most of the time. But as soon as one fallback is needed, the chip then fails continuously afterward, requiring fallback after fallback. Until the driver is reloaded. So to me, that suggests that perhaps some register has gotten corrupted, or some part of the chip has gone wanky. Perhaps if the driver could re-init more of the chip when tuning, which might correct whatever bits/state happen to need fixing? I might have a look later, and see if there are any obvious registers that perhaps I could have it dump out prior to doing the fallback, and then compare that state with a good tuning state. Or something. Cheers -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On Tue, 2010-04-13 at 08:42 -0400, Mark Lord wrote: On 13/04/10 06:35 AM, Andy Walls wrote: On Mon, 2010-04-12 at 22:34 -0400, Mark Lord wrote: .. As soon as I quit from LiveTV, the next recording still needed a new fallback. So the chip is still in some weird state where auto-audio will continue to fail until I reload the module. .. The *only* other thing I can think of, that I have control over, is the PLL charge pump current in the analog tuner. Right now it is set to low current to minimize phase noise when tuned to a channel. Perhaps setting the PLL charge pump to high current while chaning the channel to get a faster lock, and low current after a short time, will help get a good SIF output from the analog tuner assembly sooner. Perhaps when I have time .. What's weird, is that things work most of the time. But as soon as one fallback is needed, the chip then fails continuously afterward, requiring fallback after fallback. Until the driver is reloaded. Hmmm. Interesting observation. So to me, that suggests that perhaps some register has gotten corrupted, or some part of the chip has gone wanky. Perhaps if the driver could re-init more of the chip when tuning, which might correct whatever bits/state happen to need fixing? If needed, once we're in a forced mode, we could stop the microcontroller, reload all of the microcontroller firmware, and restart it. Kind of heavy handed, but it may work. I might have a look later, and see if there are any obvious registers that perhaps I could have it dump out prior to doing the fallback, and then compare that state with a good tuning state. Or something. # v4l2-dbg -d /dev/video0 -c host1 --list-registers=min=0x800,max=0x9ff Keep in mind that some of these registers aren't settable and only read out the state of various hardware blocks and functions. Dumping the state of the microcontroller memory could also be done, but I'd have to modify the driver to do it. cx18-av-firmware.c:cx18_av_verifyfw() has code that's really close to doing that. Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On 13/04/10 09:45 PM, Andy Walls wrote: .. # v4l2-dbg -d /dev/video0 -c host1 --list-registers=min=0x800,max=0x9ff Keep in mind that some of these registers aren't settable and only read out the state of various hardware blocks and functions. Dumping the state of the microcontroller memory could also be done, but I'd have to modify the driver to do it. cx18-av-firmware.c:cx18_av_verifyfw() has code that's really close to doing that. .. Thanks. I'll have a go at that some night. Meanwhile, tonight, audio failed. The syslog shows the usual fallback messages, but the audio consisted of very loud static, the kind of noise one gets when the sample bits are all reversed. While it was failing, I tried retuning, stopping/starting the recording, etc.. nothing mattered. It wanted a reload of the cx18 driver to cure it. If needed, once we're in a forced mode, we could stop the microcontroller, reload all of the microcontroller firmware, and restart it. Kind of heavy handed, but it may work. .. Perhaps that's what is needed here. Cheers -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On 14/04/10 12:32 AM, Mark Lord wrote: .. Thanks. I'll have a go at that some night. Meanwhile, tonight, audio failed. .. Oh, I forgot to include this: Apr 13 22:00:05 duke kernel: cx18-0: = START STATUS CARD #0 = Apr 13 22:00:05 duke kernel: cx18-0: Version: 1.4.0 Card: Hauppauge HVR-1600 Apr 13 22:00:05 duke kernel: tveeprom 1-0050: Hauppauge model 74551, rev C1A3, serial# 1752579 Apr 13 22:00:05 duke kernel: tveeprom 1-0050: MAC address is 00:0d:fe:1a:be:03 Apr 13 22:00:05 duke kernel: tveeprom 1-0050: tuner model is TCL MFNM05-4 (idx 103, type 43) Apr 13 22:00:05 duke kernel: tveeprom 1-0050: TV standards NTSC(M) (eeprom 0x08) Apr 13 22:00:05 duke kernel: tveeprom 1-0050: audio processor is CX23418 (idx 38) Apr 13 22:00:05 duke kernel: tveeprom 1-0050: decoder processor is CX23418 (idx 31) Apr 13 22:00:05 duke kernel: tveeprom 1-0050: has radio Apr 13 22:00:05 duke kernel: cx18-0 843: Video signal: present Apr 13 22:00:05 duke kernel: cx18-0 843: Detected format: NTSC-M Apr 13 22:00:05 duke kernel: cx18-0 843: Specified standard:NTSC-M Apr 13 22:00:05 duke kernel: cx18-0 843: Specified video input: Composite 7 Apr 13 22:00:05 duke kernel: cx18-0 843: Specified audioclock freq: 48000 Hz Apr 13 22:00:05 duke kernel: cx18-0 843: Detected audio mode: forced mode Apr 13 22:00:05 duke kernel: cx18-0 843: Detected audio standard: forced audio standard Apr 13 22:00:05 duke kernel: cx18-0 843: Audio muted: no Apr 13 22:00:05 duke kernel: cx18-0 843: Audio microcontroller: running Apr 13 22:00:05 duke kernel: cx18-0 843: Configured audio standard: BTSC Apr 13 22:00:05 duke kernel: cx18-0 843: Configured audio mode: MONO2 (LANGUAGE B) Apr 13 22:00:05 duke kernel: cx18-0 843: Specified audio input: Tuner (In8) Apr 13 22:00:05 duke kernel: cx18-0 843: Preferred audio mode: stereo Apr 13 22:00:05 duke kernel: cx18-0 gpio-reset-ctrl: GPIO: direction 0x3001, value 0x3001 Apr 13 22:00:05 duke kernel: tda9887 2-0043: Data bytes: b=0x14 c=0x30 e=0x44 Apr 13 22:00:05 duke kernel: tuner 2-0061: Tuner mode: analog TV Apr 13 22:00:05 duke kernel: tuner 2-0061: Frequency: 531.25 MHz Apr 13 22:00:05 duke kernel: tuner 2-0061: Standard:0xb000 Apr 13 22:00:05 duke kernel: cs5345 1-004c: Input: 1 Apr 13 22:00:05 duke kernel: cs5345 1-004c: Volume: 0 dB Apr 13 22:00:05 duke kernel: cx18-0: Video Input: Tuner 1 Apr 13 22:00:05 duke kernel: cx18-0: Audio Input: Tuner 1 Apr 13 22:00:05 duke kernel: cx18-0: GPIO: direction 0x3001, value 0x3001 Apr 13 22:00:05 duke kernel: cx18-0: Tuner: TV Apr 13 22:00:05 duke kernel: cx18-0: Stream: MPEG-2 Program Stream Apr 13 22:00:05 duke kernel: cx18-0: VBI Format: Private packet, IVTV format Apr 13 22:00:05 duke kernel: cx18-0: Video: 720x480, 30 fps Apr 13 22:00:05 duke kernel: cx18-0: Video: MPEG-2, 4x3, Variable Bitrate, 1200, Peak 1450 Apr 13 22:00:05 duke kernel: cx18-0: Video: GOP Size 15, 2 B-Frames, GOP Closure Apr 13 22:00:05 duke kernel: cx18-0: Audio: 48 kHz, MPEG-1/2 Layer II, 224 kbps, Stereo, No Emphasis, No CRC Apr 13 22:00:05 duke kernel: cx18-0: Spatial Filter: Manual, Luma 1D Horizontal, Chroma 1D Horizontal, 0 Apr 13 22:00:05 duke kernel: cx18-0: Temporal Filter: Manual, 8 Apr 13 22:00:05 duke kernel: cx18-0: Median Filter: Off, Luma [0, 255], Chroma [0, 255] Apr 13 22:00:05 duke kernel: cx18-0: Status flags: 0x0021 Apr 13 22:00:05 duke kernel: cx18-0: Stream encoder MPEG: status 0x0118, 0% of 2048 KiB (64 buffers) in use Apr 13 22:00:05 duke kernel: cx18-0: Stream encoder YUV: status 0x, 0% of 2025 KiB (20 buffers) in use Apr 13 22:00:05 duke kernel: cx18-0: Stream encoder VBI: status 0x0038, 5% of 1015 KiB (20 buffers) in use Apr 13 22:00:05 duke kernel: cx18-0: Stream encoder PCM audio: status 0x, 0% of 1024 KiB (256 buffers) in use Apr 13 22:00:05 duke kernel: cx18-0: Read MPEG/VBI: 190420992/476784 bytes Apr 13 22:00:05 duke kernel: cx18-0: == END STATUS CARD #0 == -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On 11/04/10 03:01 PM, Andy Walls wrote: I would be interested in hearing how frequent these patches show forced audio standard for you: .. The MythTV box here has many tuners, most of which are not used every power-up. But mythbackend _always_ initializes all tuners, and pre-tunes them to their startup channel each time the system boots up to record/play something. So.. in the logs from the other night, there are some fallback messages. But since the HVR1600 was not actually used to record anything, I don't know for sure if the audio fallback actually worked, other than that v4l-ctl reported non-muted audio afterwards. The abridged syslog is below. Something I find interesting, is that it reported having to fallback twice on this boot (once during the initial anti-stutter tune, and again when mythbackend started up). I wonder if this means that once the audio bug is present, it remains present until the next time the driver is loaded/unloaded. Which matches previous observations. The fallback (hopefully) works around this, but there's still a bug somewhere that is preventing the audio from working without the fallback. Cheers Mark Lord * * * * Apr 12 03:56:55 duke kernel: cx18: Start initialization, version 1.4.0 Apr 12 03:56:55 duke kernel: cx18-0: Initializing card 0 Apr 12 03:56:55 duke kernel: cx18-0: Autodetected Hauppauge card Apr 12 03:56:55 duke kernel: cx18 :05:03.0: PCI INT A - GSI 18 (level, low) - IRQ 18 Apr 12 03:56:55 duke kernel: cx18-0: Unreasonably low latency timer, setting to 64 (was 2) Apr 12 03:56:55 duke kernel: cx18-0: cx23418 revision 0101 (B) Apr 12 03:56:55 duke kernel: tveeprom 1-0050: Hauppauge model 74551, rev C1A3, serial# 1752579 Apr 12 03:56:55 duke kernel: tveeprom 1-0050: MAC address is 00:0d:fe:1a:be:03 Apr 12 03:56:55 duke kernel: tveeprom 1-0050: tuner model is TCL MFNM05-4 (idx 103, type 43) Apr 12 03:56:55 duke kernel: tveeprom 1-0050: TV standards NTSC(M) (eeprom 0x08) Apr 12 03:56:55 duke kernel: tveeprom 1-0050: audio processor is CX23418 (idx 38) Apr 12 03:56:55 duke kernel: tveeprom 1-0050: decoder processor is CX23418 (idx 31) Apr 12 03:56:55 duke kernel: tveeprom 1-0050: has radio Apr 12 03:56:55 duke kernel: cx18-0: Autodetected Hauppauge HVR-1600 Apr 12 03:56:55 duke kernel: cx18-0: Simultaneous Digital and Analog TV capture supported Apr 12 03:56:55 duke kernel: IRQ 18/cx18-0: IRQF_DISABLED is not guaranteed on shared IRQs Apr 12 03:56:55 duke kernel: tuner 2-0043: chip found @ 0x86 (cx18 i2c driver #0-1) Apr 12 03:56:55 duke kernel: tda9887 2-0043: creating new instance Apr 12 03:56:55 duke kernel: tda9887 2-0043: tda988[5/6/7] found Apr 12 03:56:55 duke kernel: tuner 2-0061: chip found @ 0xc2 (cx18 i2c driver #0-1) Apr 12 03:56:55 duke kernel: cs5345 1-004c: chip found @ 0x98 (cx18 i2c driver #0-0) Apr 12 03:56:55 duke kernel: tuner-simple 2-0061: creating new instance Apr 12 03:56:55 duke kernel: tuner-simple 2-0061: type set to 43 (Philips NTSC MK3 (FM1236MK3 or FM1236/F)) Apr 12 03:56:55 duke kernel: cx18-0: Registered device video1 for encoder MPEG (64 x 32.00 kB) Apr 12 03:56:55 duke kernel: DVB: registering new adapter (cx18) Apr 12 03:56:55 duke kernel: MXL5005S: Attached at address 0x63 Apr 12 03:56:55 duke kernel: DVB: registering adapter 0 frontend 0 (Samsung S5H1409 QAM/8VSB Frontend)... Apr 12 03:56:55 duke kernel: cx18-0: DVB Frontend registered Apr 12 03:56:55 duke kernel: cx18-0: Registered DVB adapter0 for TS (32 x 32.00 kB) Apr 12 03:56:55 duke kernel: cx18-0: Registered device video33 for encoder YUV (20 x 101.25 kB) Apr 12 03:56:55 duke kernel: cx18-0: Registered device vbi1 for encoder VBI (20 x 51984 bytes) Apr 12 03:56:55 duke kernel: cx18-0: Registered device video25 for encoder PCM audio (256 x 4.00 kB) Apr 12 03:56:55 duke kernel: cx18-0: Registered device radio1 for encoder radio Apr 12 03:56:55 duke kernel: cx18-0: Initialized card: Hauppauge HVR-1600 Apr 12 03:56:55 duke kernel: cx18: End initialization Apr 12 03:56:58 duke kernel: cx18 :05:03.0: firmware: requesting v4l-cx23418-cpu.fw Apr 12 03:56:58 duke kernel: cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332 bytes) Apr 12 03:56:58 duke kernel: cx18 :05:03.0: firmware: requesting v4l-cx23418-apu.fw Apr 12 03:56:58 duke kernel: cx18-0: loaded v4l-cx23418-apu.fw firmware V0012 (141200 bytes) Apr 12 03:56:58 duke kernel: cx18-0: FW version: 0.0.74.0 (Release 2007/03/12) Apr 12 03:56:58 duke kernel: cx18 :05:03.0: firmware: requesting v4l-cx23418-cpu.fw Apr 12 03:56:59 duke kernel: cx18 :05:03.0: firmware: requesting v4l-cx23418-apu.fw Apr 12 03:56:59 duke kernel: cx18 :05:03.0: firmware: requesting v4l-cx23418-dig.fw Apr 12 03:56:59 duke kernel: cx18-0 843: loaded v4l-cx23418-dig.fw firmware (16382 bytes) Apr 12 03:56:59 duke kernel: cx18-0 843: verified load of v4l-cx23418-dig.fw firmware (16382 bytes) Apr 12 03:57:00 duke kernel: ivtv :05:02.0: firmware: requesting v4l-cx2341x-enc.fw Apr 12
Re: cx18: missing audio for analog recordings
On Mon, 2010-04-12 at 16:08 -0400, Mark Lord wrote: On 11/04/10 03:01 PM, Andy Walls wrote: I would be interested in hearing how frequent these patches show forced audio standard for you: .. The MythTV box here has many tuners, most of which are not used every power-up. But mythbackend _always_ initializes all tuners, and pre-tunes them to their startup channel each time the system boots up to record/play something. So.. in the logs from the other night, there are some fallback messages. But since the HVR1600 was not actually used to record anything, I don't know for sure if the audio fallback actually worked, other than that v4l-ctl reported non-muted audio afterwards. Forcing BTSC for NTSC-M will always work. You should hear something. The abridged syslog is below. Something I find interesting, is that it reported having to fallback twice on this boot (once during the initial anti-stutter tune, BTW you shouldn't need to do that anymore. The audio stutter was a CX23418 APU and CPU firmware state problem about audio sampling rate that the newer versions of the driver handle by loading those firmwares twice and calling the APU firmware's APU_RESET_AI call. The first analog capture should never stutter anymore. and again when mythbackend started up). Whenever cx18_av_core.c:input_change() is called, the audio microcontroller audio standard autodetection is restarted. This function gets called at least once for each of these ioctl()s: VIDIOC_S_STD VIDIOC_S_FREQUENCY VIDIOC_S_INPUT and probably for some other ioctl()s as well. VIDIOC_S_FREQUENCY is called for every channel tuning operation. Your logs are probably showing the effects of calls to S_INPUT and S_FREQUENCY. You can modprobe cx18 debug=0x10 to log cx18 ioctl calls if you are interested. I wonder if this means that once the audio bug is present, it remains present until the next time the driver is loaded/unloaded. If we're talking about audio standard auto detection not working, I'll guess no. Too much really depends on the input signal quality. Auto detection working requires the analog tuner assembly to output a stable SIF signal (from the broadcaster) upon which the CX23418 A/V decoder will operate. The TV channels needs to have an audio signal. If you tune to a channel with no signal, audio autodetection will always fail and fallback to the forced mode. The cx18 driver defaults to channel 4 on startup. Which matches previous observations. The fallback (hopefully) works around this, but there's still a bug somewhere that is preventing the audio from working without the fallback. A way to test your hypothesis is to run a script that repeatedly tunes among known analog stations, perhaps with ivtv-tune, and then check the results of audio detection, perhaps with v4l2-ctl, after a few seconds. You could also save a short segment of PCM audio from /dev/video24 (or whatever) that you can check later with your own ear. My hypothesis is that once BTSC is forced once, autodetection of BTSC will more likely work well for a good number of channel changes thereafter. I do not have enough analog stations to run a test. Regards, Andy Cheers Mark Lord -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On 12/04/10 05:17 PM, Andy Walls wrote: On Mon, 2010-04-12 at 16:08 -0400, Mark Lord wrote: .. I wonder if this means that once the audio bug is present, it remains present until the next time the driver is loaded/unloaded. Which matches previous observations. The fallback (hopefully) works around this, but there's still a bug somewhere that is preventing the audio from working without the fallback. .. Okay, the fallback works -- recordings made with it do have good audio. And.. my hypothesis appears to be true thus far: once the audio fails, requiring the fallback, it stays failed until the driver is reloaded. Every subsequent recording made (after a fallback) also experiences the fallback. This is with a good channel, with good audio. Subsequent recordings using the exact same channel. Weird, eh. I wonder how to discover the real cause? Good workaround, though! Thanks. -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On 12/04/10 10:22 PM, Mark Lord wrote: .. Okay, the fallback works -- recordings made with it do have good audio. And.. my hypothesis appears to be true thus far: once the audio fails, requiring the fallback, it stays failed until the driver is reloaded. Every subsequent recording made (after a fallback) also experiences the fallback. This is with a good channel, with good audio. Subsequent recordings using the exact same channel. .. Mmm.. further to that: the problem went away as soon as I told it to tune to a different channel. No more fallbacks (for now). It can now even retune the original channel without fallbacks. So.. tuning to a new channel appears to fix whatever the bad state was that was triggering the fallbacks. Based on my sample of one, anyway. ;) Now that it is behaving again, I cannot poke further until the next time I'm lucky enough to be around when it fails. Weird, eh. I wonder how to discover the real cause? Good workaround, though! Thanks. Cheers -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On 12/04/10 10:30 PM, Mark Lord wrote: .. Mmm.. further to that: the problem went away as soon as I told it to tune to a different channel. No more fallbacks (for now). It can now even retune the original channel without fallbacks. So.. tuning to a new channel appears to fix whatever the bad state was that was triggering the fallbacks. Based on my sample of one, anyway. ;) .. Nope.. what that second email should have said, was Changing channels in LiveTV, no fallbacks required because the audio is already working from the initial fallback. As soon as I quit from LiveTV, the next recording still needed a new fallback. So the chip is still in some weird state where auto-audio will continue to fail until I reload the module. Cheers -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On Sun, 2010-04-11 at 00:56 -0400, Andy Walls wrote: On Sat, 2010-04-10 at 23:21 -0400, Mark Lord wrote: On 10/04/10 06:54 PM, Andy Walls wrote: Hmmm. Darren's having problems (loss of video/black screen) with my patches under my cx18-audio repo, but I'm not quite convinced he doesn't have some other PCI bus problem either. Anyway, my plan now is this: 1. on cx18-av-core.c:input_change() a. set register 0x808 for audio autodetection b. restart the format detection loop c. set or reset a 1.5 second timeout 2. after the timer expires, if no audio standard was detected, a. force the audio standard by programming register 0x808 (e.g. BTSC for NTSC-M) b. restart the format detection loop so the micrcontroller will do the unmute when it detects audio Darren is in NTSC-M/BTSC land. What TV standard are you dealing with? .. I'm in Canada, using the tuner for over-the-air NTSC broadcasts. Try this: http://linuxtv.org/hg/~awalls/cx18-audio2 this waits 1.5 seconds after an input/channel change to see if the audio standard micrcontroller can detect the standard. If it can't, the driver tells it to try a fallback detection. Right now, only the NTSC-M fallback detection is set to force a mode (i.e. BTSC), all the others fall back to their same auto-detection. Some annoyances with the fallback to a forced audio standard, mode, and format: 1. Static gets unmuted on stations with no signal. :( 2. I can't seem to force mode MONO2 (LANGUAGE B). I'm guessing the microcontroller keeps setting it back down to MONO1 (LANGUAGE A/Mono L +R channel for BTSC, EIAJ, A2) Feel free to experiment with the LSB of the fallback setting magic number (0x1101) in cx18-av-core.c:input_change(). I fixed #2. I had a bug so the first patch didn't properly set the fallback audio mode. I still need to fixup cx18_av_s_tuner() and cx18_av_g_tuner() to take into consideration that we might be using a forced audio mode vs. auto detection. However, that is not essential for testing; this should be good enough for testing. Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On 11/04/10 07:47 AM, Andy Walls wrote: On Sun, 2010-04-11 at 00:56 -0400, Andy Walls wrote: Try this: http://linuxtv.org/hg/~awalls/cx18-audio2 this waits 1.5 seconds after an input/channel change to see if the audio standard micrcontroller can detect the standard. If it can't, the driver tells it to try a fallback detection. Right now, only the NTSC-M fallback detection is set to force a mode (i.e. BTSC), all the others fall back to their same auto-detection. Some annoyances with the fallback to a forced audio standard, mode, and format: 1. Static gets unmuted on stations with no signal. :( 2. I can't seem to force mode MONO2 (LANGUAGE B). I'm guessing the microcontroller keeps setting it back down to MONO1 (LANGUAGE A/Mono L +R channel for BTSC, EIAJ, A2) Feel free to experiment with the LSB of the fallback setting magic number (0x1101) in cx18-av-core.c:input_change(). I fixed #2. I had a bug so the first patch didn't properly set the fallback audio mode. I still need to fixup cx18_av_s_tuner() and cx18_av_g_tuner() to take into consideration that we might be using a forced audio mode vs. auto detection. However, that is not essential for testing; this should be good enough for testing. .. Those new patches don't want to coexist with the earlier hard/soft reset changes. There's always a chance that *both* things might be needed, and the reset stuff didn't look obviously bad. Why dropped? Thanks -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On Sun, 2010-04-11 at 09:24 -0400, Mark Lord wrote: On 11/04/10 07:47 AM, Andy Walls wrote: On Sun, 2010-04-11 at 00:56 -0400, Andy Walls wrote: Try this: http://linuxtv.org/hg/~awalls/cx18-audio2 this waits 1.5 seconds after an input/channel change to see if the audio standard micrcontroller can detect the standard. If it can't, the driver tells it to try a fallback detection. Right now, only the NTSC-M fallback detection is set to force a mode (i.e. BTSC), all the others fall back to their same auto-detection. Some annoyances with the fallback to a forced audio standard, mode, and format: 1. Static gets unmuted on stations with no signal. :( 2. I can't seem to force mode MONO2 (LANGUAGE B). I'm guessing the microcontroller keeps setting it back down to MONO1 (LANGUAGE A/Mono L +R channel for BTSC, EIAJ, A2) Feel free to experiment with the LSB of the fallback setting magic number (0x1101) in cx18-av-core.c:input_change(). I fixed #2. I had a bug so the first patch didn't properly set the fallback audio mode. I still need to fixup cx18_av_s_tuner() and cx18_av_g_tuner() to take into consideration that we might be using a forced audio mode vs. auto detection. However, that is not essential for testing; this should be good enough for testing. .. Those new patches don't want to coexist with the earlier hard/soft reset changes. There's always a chance that *both* things might be needed, and the reset stuff didn't look obviously bad. Why dropped? Because... 1. Darren had problems with a black video screen with them and so did I (once I found an analog OTA station). 2. I also suspect those previous patches were not performing the format detection loop reset properly. 3. One could possibly reset the microcontroller all day long without auto-detection ever working. Also autodetection will auto-mute, and restart the detection loop, if it thinks the audio carrier went away. 4. Falling back to a known used audio standard, format, and mode is guaranteed to work. I guess it can be a problem in some region for some video stanadrd where one just can't know what each broadcaster is using. For NTSC-M this is not the case: BTSC at 4.5 MHz is always used. 5. I don't understand the exact failure mode of why the microcontroller is failing to detect the audio standard, so any other fix that doesn't explicitly set a standard will likely be unreliable. I'm tired of audio detection fixes with unpredictable outcomes based on variations in cable and OTA signal sources. Forcing the microcontroller to a particular standard, after autodetection fails, gives a deterministic outcome. (BTW, we really do need the microcontroller to do some work for us. No documentation accessable to me has enough detail to allow one to fully program the audio decoder portion of the A/V core. We have to rely on the microntroller firmware to set up some of the undocumented or unexplained registers.) I can always throw the other reset patches back in I guess, but this latest patch set should dominate the behavior of the microcontroller (if I didn't miss something because I was tired). I would be interested in hearing how frequent these patches show forced audio standard for you: [ 389.388200] cx18-0 843: Detected format: NTSC-M [ 389.388204] cx18-0 843: Specified standard:NTSC-M [ 389.388208] cx18-0 843: Specified video input: Composite 7 [ 389.388212] cx18-0 843: Specified audioclock freq: 48000 Hz [ 389.388232] cx18-0 843: Detected audio mode: forced mode [ 389.388237] cx18-0 843: Detected audio standard: forced audio standard [ 389.388241] cx18-0 843: Audio muted: no [ 389.388245] cx18-0 843: Audio microcontroller: running [ 389.388249] cx18-0 843: Configured audio standard: BTSC [ 389.388253] cx18-0 843: Configured audio mode: MONO2 (LANGUAGE B) [ 389.388257] cx18-0 843: Specified audio input: Tuner (In8) [ 389.388261] cx18-0 843: Preferred audio mode: stereo meaning that the fallback audio settings were used because auto detection failed. Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
Andy Walls wrote: On Sat, 2010-04-10 at 23:21 -0400, Mark Lord wrote: On 10/04/10 06:54 PM, Andy Walls wrote: Hmmm. Darren's having problems (loss of video/black screen) with my patches under my cx18-audio repo, but I'm not quite convinced he doesn't have some other PCI bus problem either. Anyway, my plan now is this: 1. on cx18-av-core.c:input_change() a. set register 0x808 for audio autodetection b. restart the format detection loop c. set or reset a 1.5 second timeout 2. after the timer expires, if no audio standard was detected, a. force the audio standard by programming register 0x808 (e.g. BTSC for NTSC-M) b. restart the format detection loop so the micrcontroller will do the unmute when it detects audio Darren is in NTSC-M/BTSC land. What TV standard are you dealing with? .. I'm in Canada, using the tuner for over-the-air NTSC broadcasts. Try this: http://linuxtv.org/hg/~awalls/cx18-audio2 this waits 1.5 seconds after an input/channel change to see if the audio standard micrcontroller can detect the standard. If it can't, the driver tells it to try a fallback detection. Right now, only the NTSC-M fallback detection is set to force a mode (i.e. BTSC), all the others fall back to their same auto-detection. Some annoyances with the fallback to a forced audio standard, mode, and format: 1. Static gets unmuted on stations with no signal. :( 2. I can't seem to force mode MONO2 (LANGUAGE B). I'm guessing the microcontroller keeps setting it back down to MONO1 (LANGUAGE A/Mono L +R channel for BTSC, EIAJ, A2) Feel free to experiment with the LSB of the fallback setting magic number (0x1101) in cx18-av-core.c:input_change(). Regards, Andy So far, it seems fine, no black screens, and audio seems to be fine. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On 11/04/10 03:01 PM, Andy Walls wrote: .. I can always throw the other reset patches back in I guess, but this latest patch set should dominate the behavior of the microcontroller (if I didn't miss something because I was tired). I would be interested in hearing how frequent these patches show forced audio standard for you: .. Thanks. Will do. I've added a printk() to the fallback path, so that it will show up in the syslog whenever the fallback is used. So far, no problem. But prior to now, the HVR-1600 regularly failed about once every 2-3 days according to the script I have which tests for the issue. On a similar note, while checking the logs last evening, I discovered that the muted episode of Survivor Heros Villians (two weeks ago) was actually recorded on the _PVR-250_ card. With no audio. This has happened before, though rarely -- perhaps once every 3-6 months or so. I wonder if a similar fix/workaround could be appropriate for that card as well? In the mean while, I guess I'll update my scripts to test/report for that one as well as the cx18/hvr1600. Cheers -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On 15/03/10 07:51 AM, Andy Walls wrote:
On Sun, 2010-03-14 at 22:48 -0400, Mark Lord wrote:
On 03/02/10 07:40, Andy Walls wrote:
..
after updating to the tip of the v4l2-dvb git tree last week,
I've been hitting the no audio on analog recordings bug much more often.
Digging through google, it appears this problem has been around as long
as the cx18 driver has existed, with no clear resolution. Lots of people
have reported it to you before, and nobody has found a silver bullet fix.
..
Here are all the potential problem areas I can think of:
1. A/V digitizer/decoder audio detection firmware load and init. (I've
added firmware readback verification to try and head this off.)
2. A/V digitizer decoder audio microcontroller hard reset and soft
reset sequencing. (I think the cx18 driver has this wrong ATM.)
3. APU load and init. (The double load is to fix a DTV TS stream bug on
every other APU CPU firmware load sequence. The APU_AI_RESET is to
fix the audio bitrate problem on first capture after a double firmware
load.)
4. AI1 Mux setting failing when switching between the internal A/V
decoder's I2S output and the external I2S inputs. (I thought I had this
fixed, but I don't have detailed register specs for that register - so
maybe not.)
5. A/V decoder audio clock PLL stops operating due to being programmed
out of range. (This was a problem for 32 ksps audio a while ago, but
I'm pretty confident I have it fixed.)
6. A/V decoder analog frontend setup for SIF wrong?. (I fixed this due
to a problen Helen Buus reported with cable TV.)
I think #2 is the real problem. I just started to disassmble the
digitizer firmware 2 nights ago to see if I could get some insight as to
how to properly reset it.
I've got a first WAG at fixing the resets of the audio microcontroller's
resets at:
http://linuxtv.org/hg/~awalls/cx18-audio
If it doesn't work, change the CXADEC_AUDIO_SOFT_RESET register define
from 0x810 to 0x9cc, although that may not work either.
..
Thanks for the troubleshooting and reporting.
..
Back at this again today, after a month away from it -- getting tired
of watching Survivor with closed-captioning instead of audio. :)
I pulled your (Andy) repository today, and merged the cx18 audio reset
changes from it into today's tip from v4l-dvb. Patch attached for reference.
So far, so good. I'll keep tabs on it over time, and see if the audio
is stable, or if it still fails once in a while.
Cheers
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
--- v4l-dvb-7c0b887911cf/linux/drivers/media/video/cx18/cx18-av-audio.c
2010-04-05 22:56:43.0 -0400
+++ patched/linux/drivers/media/video/cx18/cx18-av-audio.c 2010-03-13
22:06:55.0 -0500
@@ -305,14 +305,14 @@
struct cx18_av_state *state = cx-av_state;
u8 v;
+ /* assert soft reset */
+ v = cx18_av_read(cx, CXADEC_AUDIO_SOFT_RESET) | 0x01;
+ cx18_av_write_expect(cx, CXADEC_AUDIO_SOFT_RESET, v, v, 0x0f);
+
/* stop microcontroller */
v = cx18_av_read(cx, 0x803) ~0x10;
cx18_av_write_expect(cx, 0x803, v, v, 0x1f);
- /* assert soft reset */
- v = cx18_av_read(cx, 0x810) | 0x01;
- cx18_av_write_expect(cx, 0x810, v, v, 0x0f);
-
/* Mute everything to prevent the PFFT! */
cx18_av_write(cx, 0x8d3, 0x1f);
@@ -330,16 +330,17 @@
set_audclk_freq(cx, state-audclk_freq);
- /* deassert soft reset */
- v = cx18_av_read(cx, 0x810) ~0x01;
- cx18_av_write_expect(cx, 0x810, v, v, 0x0f);
-
if (state-aud_input CX18_AV_AUDIO_SERIAL2) {
+ /* start microcontroller */
/* When the microcontroller detects the
* audio format, it will unmute the lines */
v = cx18_av_read(cx, 0x803) | 0x10;
cx18_av_write_expect(cx, 0x803, v, v, 0x1f);
}
+
+ /* deassert soft reset */
+ v = cx18_av_read(cx, CXADEC_AUDIO_SOFT_RESET) ~0x01;
+ cx18_av_write_expect(cx, CXADEC_AUDIO_SOFT_RESET, v, v, 0x0f);
}
static int get_volume(struct cx18 *cx)
@@ -449,12 +450,13 @@
* changes to the mute register. */
v = cx18_av_read(cx, 0x803);
if (mute) {
- /* disable microcontroller */
+ /* stop microcontroller */
v = ~0x10;
cx18_av_write_expect(cx, 0x803, v, v, 0x1f);
+ /* mute all of Path 1 */
cx18_av_write(cx, 0x8d3, 0x1f);
} else {
- /* enable microcontroller */
+ /* start microcontroller */
v |= 0x10;
cx18_av_write_expect(cx, 0x803, v, v, 0x1f);
}
@@ -471,22 +473,29 @@
int retval;
u8 v;
+ /* assert soft reset */
+ v = cx18_av_read(cx, CXADEC_AUDIO_SOFT_RESET) | 0x1;
+
Re: cx18: missing audio for analog recordings
On Sat, 2010-04-10 at 18:28 -0400, Mark Lord wrote: On 15/03/10 07:51 AM, Andy Walls wrote: On Sun, 2010-03-14 at 22:48 -0400, Mark Lord wrote: On 03/02/10 07:40, Andy Walls wrote: .. after updating to the tip of the v4l2-dvb git tree last week, I've been hitting the no audio on analog recordings bug much more often. Digging through google, it appears this problem has been around as long as the cx18 driver has existed, with no clear resolution. Lots of people have reported it to you before, and nobody has found a silver bullet fix. .. Here are all the potential problem areas I can think of: 1. A/V digitizer/decoder audio detection firmware load and init. (I've added firmware readback verification to try and head this off.) 2. A/V digitizer decoder audio microcontroller hard reset and soft reset sequencing. (I think the cx18 driver has this wrong ATM.) 3. APU load and init. (The double load is to fix a DTV TS stream bug on every other APU CPU firmware load sequence. The APU_AI_RESET is to fix the audio bitrate problem on first capture after a double firmware load.) 4. AI1 Mux setting failing when switching between the internal A/V decoder's I2S output and the external I2S inputs. (I thought I had this fixed, but I don't have detailed register specs for that register - so maybe not.) 5. A/V decoder audio clock PLL stops operating due to being programmed out of range. (This was a problem for 32 ksps audio a while ago, but I'm pretty confident I have it fixed.) 6. A/V decoder analog frontend setup for SIF wrong?. (I fixed this due to a problen Helen Buus reported with cable TV.) I think #2 is the real problem. I just started to disassmble the digitizer firmware 2 nights ago to see if I could get some insight as to how to properly reset it. I've got a first WAG at fixing the resets of the audio microcontroller's resets at: http://linuxtv.org/hg/~awalls/cx18-audio If it doesn't work, change the CXADEC_AUDIO_SOFT_RESET register define from 0x810 to 0x9cc, although that may not work either. .. Thanks for the troubleshooting and reporting. .. Back at this again today, after a month away from it -- getting tired of watching Survivor with closed-captioning instead of audio. :) I pulled your (Andy) repository today, and merged the cx18 audio reset changes from it into today's tip from v4l-dvb. Patch attached for reference. So far, so good. I'll keep tabs on it over time, and see if the audio is stable, or if it still fails once in a while. Hmmm. Darren's having problems (loss of video/black screen) with my patches under my cx18-audio repo, but I'm not quite convinced he doesn't have some other PCI bus problem either. Anyway, my plan now is this: 1. on cx18-av-core.c:input_change() a. set register 0x808 for audio autodetection b. restart the format detection loop c. set or reset a 1.5 second timeout 2. after the timer expires, if no audio standard was detected, a. force the audio standard by programming register 0x808 (e.g. BTSC for NTSC-M) b. restart the format detection loop so the micrcontroller will do the unmute when it detects audio Darren is in NTSC-M/BTSC land. What TV standard are you dealing with? Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On Sat, 2010-04-10 at 18:54 -0400, Andy Walls wrote: On Sat, 2010-04-10 at 18:28 -0400, Mark Lord wrote: On 15/03/10 07:51 AM, Andy Walls wrote: On Sun, 2010-03-14 at 22:48 -0400, Mark Lord wrote: On 03/02/10 07:40, Andy Walls wrote: .. after updating to the tip of the v4l2-dvb git tree last week, I've been hitting the no audio on analog recordings bug much more often. Digging through google, it appears this problem has been around as long as the cx18 driver has existed, with no clear resolution. Lots of people have reported it to you before, and nobody has found a silver bullet fix. .. Here are all the potential problem areas I can think of: 1. A/V digitizer/decoder audio detection firmware load and init. (I've added firmware readback verification to try and head this off.) 2. A/V digitizer decoder audio microcontroller hard reset and soft reset sequencing. (I think the cx18 driver has this wrong ATM.) 3. APU load and init. (The double load is to fix a DTV TS stream bug on every other APU CPU firmware load sequence. The APU_AI_RESET is to fix the audio bitrate problem on first capture after a double firmware load.) 4. AI1 Mux setting failing when switching between the internal A/V decoder's I2S output and the external I2S inputs. (I thought I had this fixed, but I don't have detailed register specs for that register - so maybe not.) 5. A/V decoder audio clock PLL stops operating due to being programmed out of range. (This was a problem for 32 ksps audio a while ago, but I'm pretty confident I have it fixed.) 6. A/V decoder analog frontend setup for SIF wrong?. (I fixed this due to a problen Helen Buus reported with cable TV.) I think #2 is the real problem. I just started to disassmble the digitizer firmware 2 nights ago to see if I could get some insight as to how to properly reset it. I've got a first WAG at fixing the resets of the audio microcontroller's resets at: http://linuxtv.org/hg/~awalls/cx18-audio If it doesn't work, change the CXADEC_AUDIO_SOFT_RESET register define from 0x810 to 0x9cc, although that may not work either. .. Thanks for the troubleshooting and reporting. .. Back at this again today, after a month away from it -- getting tired of watching Survivor with closed-captioning instead of audio. :) I pulled your (Andy) repository today, and merged the cx18 audio reset changes from it into today's tip from v4l-dvb. Patch attached for reference. So far, so good. I'll keep tabs on it over time, and see if the audio is stable, or if it still fails once in a while. Hmmm. Darren's having problems (loss of video/black screen) with my patches under my cx18-audio repo, but I'm not quite convinced he doesn't have some other PCI bus problem either. Anyway, my plan now is this: 1. on cx18-av-core.c:input_change() a. set register 0x808 for audio autodetection b. restart the format detection loop c. set or reset a 1.5 second timeout 2. after the timer expires, if no audio standard was detected, a. force the audio standard by programming register 0x808 (e.g. BTSC for NTSC-M) b. restart the format detection loop so the micrcontroller will do the unmute when it detects audio Darren is in NTSC-M/BTSC land. What TV standard are you dealing with? Hey, I just found an OTA analog broadcast on channel 23! I even can reproduce the problem of the audio microcontroller not detecting the audio standard (shoot it just kicked in and figured it out). Anyway this will help me turn around something. Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On 10/04/10 06:54 PM, Andy Walls wrote: Hmmm. Darren's having problems (loss of video/black screen) with my patches under my cx18-audio repo, but I'm not quite convinced he doesn't have some other PCI bus problem either. Anyway, my plan now is this: 1. on cx18-av-core.c:input_change() a. set register 0x808 for audio autodetection b. restart the format detection loop c. set or reset a 1.5 second timeout 2. after the timer expires, if no audio standard was detected, a. force the audio standard by programming register 0x808 (e.g. BTSC for NTSC-M) b. restart the format detection loop so the micrcontroller will do the unmute when it detects audio Darren is in NTSC-M/BTSC land. What TV standard are you dealing with? .. I'm in Canada, using the tuner for over-the-air NTSC broadcasts. Cheers! -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On Sat, 2010-04-10 at 23:21 -0400, Mark Lord wrote: On 10/04/10 06:54 PM, Andy Walls wrote: Hmmm. Darren's having problems (loss of video/black screen) with my patches under my cx18-audio repo, but I'm not quite convinced he doesn't have some other PCI bus problem either. Anyway, my plan now is this: 1. on cx18-av-core.c:input_change() a. set register 0x808 for audio autodetection b. restart the format detection loop c. set or reset a 1.5 second timeout 2. after the timer expires, if no audio standard was detected, a. force the audio standard by programming register 0x808 (e.g. BTSC for NTSC-M) b. restart the format detection loop so the micrcontroller will do the unmute when it detects audio Darren is in NTSC-M/BTSC land. What TV standard are you dealing with? .. I'm in Canada, using the tuner for over-the-air NTSC broadcasts. Try this: http://linuxtv.org/hg/~awalls/cx18-audio2 this waits 1.5 seconds after an input/channel change to see if the audio standard micrcontroller can detect the standard. If it can't, the driver tells it to try a fallback detection. Right now, only the NTSC-M fallback detection is set to force a mode (i.e. BTSC), all the others fall back to their same auto-detection. Some annoyances with the fallback to a forced audio standard, mode, and format: 1. Static gets unmuted on stations with no signal. :( 2. I can't seem to force mode MONO2 (LANGUAGE B). I'm guessing the microcontroller keeps setting it back down to MONO1 (LANGUAGE A/Mono L +R channel for BTSC, EIAJ, A2) Feel free to experiment with the LSB of the fallback setting magic number (0x1101) in cx18-av-core.c:input_change(). Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ivtv-devel] cx18: missing audio for analog recordings
On Sun, 2010-04-11 at 00:56 -0400, Andy Walls wrote: On Sat, 2010-04-10 at 23:21 -0400, Mark Lord wrote: On 10/04/10 06:54 PM, Andy Walls wrote: Hmmm. Darren's having problems (loss of video/black screen) with my patches under my cx18-audio repo, but I'm not quite convinced he doesn't have some other PCI bus problem either. Anyway, my plan now is this: 1. on cx18-av-core.c:input_change() a. set register 0x808 for audio autodetection b. restart the format detection loop c. set or reset a 1.5 second timeout 2. after the timer expires, if no audio standard was detected, a. force the audio standard by programming register 0x808 (e.g. BTSC for NTSC-M) b. restart the format detection loop so the micrcontroller will do the unmute when it detects audio Darren is in NTSC-M/BTSC land. What TV standard are you dealing with? .. I'm in Canada, using the tuner for over-the-air NTSC broadcasts. Try this: http://linuxtv.org/hg/~awalls/cx18-audio2 this waits 1.5 seconds after an input/channel change to see if the audio standard micrcontroller can detect the standard. If it can't, the driver tells it to try a fallback detection. Right now, only the NTSC-M fallback detection is set to force a mode (i.e. BTSC), all the others fall back to their same auto-detection. Some annoyances with the fallback to a forced audio standard, mode, and format: 1. Static gets unmuted on stations with no signal. :( 2. I can't seem to force mode MONO2 (LANGUAGE B). I'm guessing the microcontroller keeps setting it back down to MONO1 (LANGUAGE A/Mono L +R channel for BTSC, EIAJ, A2) Feel free to experiment with the LSB of ^^^ Bah, wrong byte. That should have been the LSN of the MSB of the 0x1101 number. I'm too tired. Regards, Andy the fallback setting magic number (0x1101) in cx18-av-core.c:input_change(). Regards, Andy ___ ivtv-devel mailing list ivtv-de...@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On Tue, 2010-03-16 at 00:49 -0400, Mark Lord wrote: On 03/15/10 07:51, Andy Walls wrote: On Sun, 2010-03-14 at 22:48 -0400, Mark Lord wrote: If the audio is not working after modprobe, then simply doing rmmod/modprobe in a loop (until working audio is achieved) is enough to cure it. .. Well, crap. Tonight our MythTV box proved that assertion to be false. The cx18 audio was okay after modprobe, but went bad a few seconds later, when mythbackend started up and did the initial channel tuning. I have a script that attempts audio input toggling when that happens, but it had no effect. I'll note from your logs that you're capturing using the 48 ksps audio sampling rate with tuner audio. I've never had a problem with the AUX_PLL with 48 ksps audio, so I'm going to assume the AUX_PLL isn't the problem's cause. rmmod/modprobe is still the only solution, and it's rather difficult to do those while mythbackend is running. I've got a first WAG at fixing the resets of the audio microcontroller's resets at: http://linuxtv.org/hg/~awalls/cx18-audio If it doesn't work, change the CXADEC_AUDIO_SOFT_RESET register define from 0x810 to 0x9cc, although that may not work either. .. I'll have a go at that, and anything else you can dream up as well. Here's an easy one: I see from the log your work-around is failing: Mar 13 14:30:04 duke logger: /dev/video1: fix_hvr1600_stutter.sh: Pre-initializing Mar 13 14:30:09 duke logger: /dev/video1: fix_hvr1600_stutter.sh: HVR1600/cx18 audio bug, reloading cx18 driver Mar 13 14:30:09 duke logger: /dev/video1: fix_hvr1600_stutter.sh: rmmod cx18 failed If a cx18 video device node is open or a cx18-alsa device node is open you won't be able to unload the cx18 and cx18-alsa modules. Move the cx18-alsa.ko module out of the way so the kernel can't find it and load it. Then you never have to worry about something like pulseaduio keeping it held open. I see in your log that this is a tuner audio standard autodetection problem in the A/V digitizer/decoder: Mar 13 14:42:16 duke kernel: cx18-0 843: Video signal: present Mar 13 14:42:16 duke kernel: cx18-0 843: Detected format: NTSC-M Mar 13 14:42:16 duke kernel: cx18-0 843: Specified standard:NTSC-M Mar 13 14:42:16 duke kernel: cx18-0 843: Specified video input: Composite 7 Mar 13 14:42:16 duke kernel: cx18-0 843: Specified audioclock freq: 48000 Hz Mar 13 14:42:16 duke kernel: cx18-0 843: Detected audio mode: mono Mar 13 14:42:16 duke kernel: cx18-0 843: Detected audio standard: no detected audio standard Mar 13 14:42:16 duke kernel: cx18-0 843: Audio muted: yes Mar 13 14:42:16 duke kernel: cx18-0 843: Audio microcontroller: running Mar 13 14:42:16 duke kernel: cx18-0 843: Configured audio standard: automatic detection Mar 13 14:42:16 duke kernel: cx18-0 843: Configured audio system: BTSC Mar 13 14:42:16 duke kernel: cx18-0 843: Specified audio input: Tuner (In8) Mar 13 14:42:16 duke kernel: cx18-0 843: Preferred audio mode: stereo The built-in A/V digitzer/decoder's microcontroller won't unmute the audio until it has detected the standard and set the registers. I also note the channel change (audio input toggling from tuner to composite in and back?) is having no effect: Mar 13 14:30:23 duke logger: /dev/video1: channel_change: hit HVR1600/cx18 audio bug.. attempting workaround Mar 13 14:30:24 duke logger: /dev/video1: channel_change: hit HVR1600/cx18 audio bug.. workaround failed Which means the audio microcontroller didn't restart it's detection loop or the detection loop is still failing to find anything. It should restart on an input toggle. This means your problem is occuring in the A/V digitizer or before it; ruling out the APU or the APU firmware, given the current information. So the areas to concentrate on here are: a. digitizer audio standard detection microcontroller intitialization, reset, and restart of the format detection loop b. TDA9887 analog IF demodulator programming via the CX23418's I2C master c. digitizer audio standard detection microcontroller firmware load and verification (the cx18 driver already does a lot here, but it may be worth re-inspecting the code) d. digitizer analog front end and AUX PLL settings for SIF audio (these should be correct though, so it is unlikely to be the problem) But not for a few days -- really really crazy busy at work right now. Same here. Crazy at work and home. I don't mind waiting. I am a Linux kernel developer, so I can handle patches and stuff if you have any to offer. I'll keep that in mind. Oh.. attached is a full log from a failure a few nights ago. This one has the full card status dump included, which shows where the audio is being muted at. ... With that said, the CX23418 will sometimes have to let register access over the PCI bus fail. For that, I have routines in cx18-io.[ch] to perform retries.
Re: cx18: missing audio for analog recordings
On Sun, 2010-03-14 at 22:48 -0400, Mark Lord wrote: On 03/02/10 07:40, Andy Walls wrote: Again, maybe dynamically allocating these work order objects from the kernel as needed, would be better from a small dynamically allocated pool for each card. I was concerned that the interrupt handler was taking to long at the time I implemented the things the way they are now. .. I haven't seen that particular issue again, with or without increasing the work orders, so hopefully it won't recur. OK. But after updating to the tip of the v4l2-dvb git tree last week, I've been hitting the no audio on analog recordings bug much more often. Is that tuner audio or baseband (line-in) audio? Digging through google, it appears this problem has been around as long as the cx18 driver has existed, with no clear resolution. Lots of people have reported it to you before, and nobody has found a silver bullet fix. Correct. I thought it was completely gone, but apparently, there just isn't a lot of reporting of this intermittent problem. The problem is still there. I have now spent a good many hours trying to isolate *when* it happens, and have narrowed it down to module initialization. Basically, if the audio is working after modprobe cx18, it then continues to work from recording to recording until the next reboot. If the audio is not working after modprobe, then simply doing rmmod/modprobe in a loop (until working audio is achieved) is enough to cure it. Good to know. So for my Mythtv box here, I now have a script to check for missing audio and do the rmmod/modprobe. This is a good, effective workaround. http://rtr.ca/hvr1600/fix_hvr1600_audio.sh That's a link to my script. As for the actual underlying cause/bug, it's still not clear what is happening. But the problem is a LOT more prevalent (for me, and for two other people I know) with versions of the cx18 driver since spring 2009. My suspicion is that the firmware download for the APU is somehow being corrupted, and now that the driver downloads the firmware *twice* during init, it doubles the odds of said corruption. Just a theory, but it's the best fit so far. Please isolate an APU load and initialization problem, by seeing if audio fails for both tuner audio and baseband audio. Here are all the potential problem areas I can think of: 1. A/V digitizer/decoder audio detection firmware load and init. (I've added firmware readback verification to try and head this off.) 2. A/V digitizer decoder audio microcontroller hard reset and soft reset sequencing. (I think the cx18 driver has this wrong ATM.) 3. APU load and init. (The double load is to fix a DTV TS stream bug on every other APU CPU firmware load sequence. The APU_AI_RESET is to fix the audio bitrate problem on first capture after a double firmware load.) 4. AI1 Mux setting failing when switching between the internal A/V decoder's I2S output and the external I2S inputs. (I thought I had this fixed, but I don't have detailed register specs for that register - so maybe not.) 5. A/V decoder audio clock PLL stops operating due to being programmed out of range. (This was a problem for 32 ksps audio a while ago, but I'm pretty confident I have it fixed.) 6. A/V decoder analog frontend setup for SIF wrong?. (I fixed this due to a problen Helen Buus reported with cable TV.) I think #2 is the real problem. I just started to disassmble the digitizer firmware 2 nights ago to see if I could get some insight as to how to properly reset it. I've got a first WAG at fixing the resets of the audio microcontroller's resets at: http://linuxtv.org/hg/~awalls/cx18-audio If it doesn't work, change the CXADEC_AUDIO_SOFT_RESET register define from 0x810 to 0x9cc, although that may not work either. I think we have some nasty i2c issues somewhere in the kernel. The only I2C connected devices for analog audio are the analog tuner IF demodulator chip for SIF audio and the CS5345 chip for baseband audio. Unlike the PVR-150, which has an I2C connected CX25843 A/V decoder, the CX23418's A/V decoder is integrated and accessed via PCI bus registers. With that said, the CX23418 will sometimes have to let register access over the PCI bus fail. For that, I have routines in cx18-io.[ch] to perform retries. You may wish to add a log statement there to watch for retry loops that completely fail. Thanks for the troubleshooting and reporting. Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cx18: missing audio for analog recordings
On 03/02/10 07:40, Andy Walls wrote: Again, maybe dynamically allocating these work order objects from the kernel as needed, would be better from a small dynamically allocated pool for each card. I was concerned that the interrupt handler was taking to long at the time I implemented the things the way they are now. .. I haven't seen that particular issue again, with or without increasing the work orders, so hopefully it won't recur. But after updating to the tip of the v4l2-dvb git tree last week, I've been hitting the no audio on analog recordings bug much more often. Digging through google, it appears this problem has been around as long as the cx18 driver has existed, with no clear resolution. Lots of people have reported it to you before, and nobody has found a silver bullet fix. The problem is still there. I have now spent a good many hours trying to isolate *when* it happens, and have narrowed it down to module initialization. Basically, if the audio is working after modprobe cx18, it then continues to work from recording to recording until the next reboot. If the audio is not working after modprobe, then simply doing rmmod/modprobe in a loop (until working audio is achieved) is enough to cure it. So for my Mythtv box here, I now have a script to check for missing audio and do the rmmod/modprobe. This is a good, effective workaround. http://rtr.ca/hvr1600/fix_hvr1600_audio.sh That's a link to my script. As for the actual underlying cause/bug, it's still not clear what is happening. But the problem is a LOT more prevalent (for me, and for two other people I know) with versions of the cx18 driver since spring 2009. My suspicion is that the firmware download for the APU is somehow being corrupted, and now that the driver downloads the firmware *twice* during init, it doubles the odds of said corruption. Just a theory, but it's the best fit so far. I think we have some nasty i2c issues somewhere in the kernel. Cheers -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
