Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 21 Mar 1997 19:32:55 -0700
From:      Steve Passe <smp@csn.net>
To:        Randall Hopper <rhh@ct.picker.com>
Cc:        multimedia@freebsd.org
Subject:   Re: FXTV v0.3 available 
Message-ID:  <199703220232.TAA28406@Ilsa.StevesCafe.com>
In-Reply-To: Your message of "Fri, 21 Mar 1997 17:57:05 EST." <19970321175705.45910@ct.picker.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703220232.TAA28406>