From owner-freebsd-multimedia  Fri Mar 21 18:33:07 1997
Return-Path: <owner-multimedia>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id SAA03687
          for multimedia-outgoing; Fri, 21 Mar 1997 18:33:07 -0800 (PST)
Received: from Ilsa.StevesCafe.com (sc-gw.StevesCafe.com [205.168.119.191])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA03680
          for <multimedia@freebsd.org>; Fri, 21 Mar 1997 18:33:00 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.7.5/8.6.12) with SMTP id TAA28406; Fri, 21 Mar 1997 19:32:55 -0700 (MST)
Message-Id: <199703220232.TAA28406@Ilsa.StevesCafe.com>
X-Authentication-Warning: Ilsa.StevesCafe.com: Host localhost [127.0.0.1] didn't use HELO protocol
X-Mailer: exmh version 1.6.5 12/11/95
From: Steve Passe <smp@csn.net>
To: Randall Hopper <rhh@ct.picker.com>
cc: multimedia@freebsd.org
Subject: Re: FXTV v0.3 available 
In-reply-to: Your message of "Fri, 21 Mar 1997 17:57:05 EST."
             <19970321175705.45910@ct.picker.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 21 Mar 1997 19:32:55 -0700
Sender: owner-multimedia@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Hi,

> However, if freeze-frame is invoked (CAP_SINGLE) while watching/listening
> to the tuner (DEV1), that seems to flip the audio back to the "video"
> (DEV0) device and it doesn't come back to the tuner when the display is
> unfrozen (i.e. back to CAP_CONTINUOUS) and the tuner display continues.
> Switching the input device away from tuner and then back to tuner seems the
> only thing that gets the audio back.

I found the offending lines:
  in bktr_ioctl():
 ...
	case METEORCAPTUR:
 ...
			btl_reg = (u_long *) &bt848[BKTR_GPIO_OUT_EN];
			*btl_reg = 1;

this is effectivly muting the audio output by dropping the drive to
ONE of the mux pins, but NOT the other.  I can't determine what it was
logically meant to do here.  If it was done to mute the audio it is 
the wrong method for the current model.  Just remove these 2
lines and the problem goes away.  Note that the audio now continues
even thought the video freezes.  The app should control audio separately
via set_audio( AUDIO_MUTE ) & set_audio( AUDIO_UNMUTE ) if it wants
muting during the capture.

--
Steve Passe	| powered by 
smp@csn.net	|            Symmetric MultiProcessor FreeBSD