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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
