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
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
