Skip to content

L
linux
Commit 2287cb47 authored by Mauro Carvalho Chehab's avatar Mauro Carvalho Chehab
Browse files
Options

[media] doc-rst: move bttv documentation to bttv.rst file 

There were several files under Documentation/video4linux/bttv.

Instead of simply copying them to the rst folder, I opted to
merge into a single document and adjust the headers to
adjust the section levels and fix the cards tables.

There are two exceptions on the merge:

- The Tuners were renamed as a separate document, as they
  describe a separate driver;

- I removed the PROBLEMS section. It describes problems with
  the very first generation of 3D boards (Mistique/S3).
  It sounds very unlikely that someone would still need to
  install a bttv board on such hardware. Also, it is not
  very well written, IMHO.
Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
parent 2e97d6d3
Expand all Hide whitespace changes
Inline Side-by-side
Showing with 1881 additions and 1763 deletions
Documentation/media/v4l-drivers/bttv.rst 0 → 100644
View file @ 2287cb47
This diff is collapsed.
Documentation/video4linux/bttv/CONTRIBUTORS deleted 100644 → 0
View file @ 2e97d6d3
Contributors to bttv:
Michael Chu <mmchu@pobox.com>
AverMedia fix and more flexible card recognition
Alan Cox <alan@lxorguk.ukuu.org.uk>
Video4Linux interface and 2.1.x kernel adaptation
Chris Kleitsch
Hardware I2C
Gerd Knorr <kraxel@cs.tu-berlin.de>
Radio card (ITT sound processor)
bigfoot <bigfoot@net-way.net>
Ragnar Hojland Espinosa <ragnar@macula.net>
ConferenceTV card
+ many more (please mail me if you are missing in this list and would
like to be mentioned)
Documentation/video4linux/bttv/Cards deleted 100644 → 0
View file @ 2e97d6d3
This diff is collapsed.
Documentation/video4linux/bttv/ICs deleted 100644 → 0
View file @ 2e97d6d3
all boards:
Brooktree Bt848/848A/849/878/879: video capture chip
Miro PCTV:
Philips or Temic Tuner
Hauppauge Win/TV pci (version 405):
Microchip 24LC02B or
Philips 8582E2Y: 256 Byte EEPROM with configuration information
I2C 0xa0-0xa1, (24LC02B also responds to 0xa2-0xaf)
Philips SAA5246AGP/E: Videotext decoder chip, I2C 0x22-0x23
TDA9800: sound decoder
Winbond W24257AS-35: 32Kx8 CMOS static RAM (Videotext buffer mem)
14052B: analog switch for selection of sound source
PAL:
TDA5737: VHF, hyperband and UHF mixer/oscillator for TV and VCR 3-band tuners
TSA5522: 1.4 GHz I2C-bus controlled synthesizer, I2C 0xc2-0xc3
NTSC:
TDA5731: VHF, hyperband and UHF mixer/oscillator for TV and VCR 3-band tuners
TSA5518: no datasheet available on Philips site
STB TV pci:
???
if you want better support for STB cards send me info!
Look at the board! What chips are on it?
Documentation/video4linux/bttv/Insmod-options deleted 100644 → 0
View file @ 2e97d6d3
Note: "modinfo <module>" prints various information about a kernel
module, among them a complete and up-to-date list of insmod options.
This list tends to be outdated because it is updated manually ...
==========================================================================
bttv.o
the bt848/878 (grabber chip) driver
insmod args:
card=n card type, see CARDLIST for a list.
tuner=n tuner type, see CARDLIST for a list.
radio=0/1 card supports radio
pll=0/1/2 pll settings
0: don't use PLL
1: 28 MHz crystal installed
2: 35 MHz crystal installed
triton1=0/1 for Triton1 (+others) compatibility
vsfx=0/1 yet another chipset bug compatibility bit
see README.quirks for details on these two.
bigendian=n Set the endianness of the gfx framebuffer.
Default is native endian.
fieldnr=0/1 Count fields. Some TV descrambling software
needs this, for others it only generates
50 useless IRQs/sec. default is 0 (off).
autoload=0/1 autoload helper modules (tuner, audio).
default is 1 (on).
bttv_verbose=0/1/2 verbose level (at insmod time, while
looking at the hardware). default is 1.
bttv_debug=0/1 debug messages (for capture).
default is 0 (off).
irq_debug=0/1 irq handler debug messages.
default is 0 (off).
gbuffers=2-32 number of capture buffers for mmap'ed capture.
default is 4.
gbufsize= size of capture buffers. default and
maximum value is 0x208000 (~2MB)
no_overlay=0 Enable overlay on broken hardware. There
are some chipsets (SIS for example) which
are known to have problems with the PCI DMA
push used by bttv. bttv will disable overlay
by default on this hardware to avoid crashes.
With this insmod option you can override this.
no_overlay=1 Disable overlay. It should be used by broken
hardware that doesn't support PCI2PCI direct
transfers.
automute=0/1 Automatically mutes the sound if there is
no TV signal, on by default. You might try
to disable this if you have bad input signal
quality which leading to unwanted sound
dropouts.
chroma_agc=0/1 AGC of chroma signal, off by default.
adc_crush=0/1 Luminance ADC crush, on by default.
i2c_udelay= Allow reduce I2C speed. Default is 5 usecs
(meaning 66,67 Kbps). The default is the
maximum supported speed by kernel bitbang
algorithm. You may use lower numbers, if I2C
messages are lost (16 is known to work on
all supported cards).
bttv_gpio=0/1
gpiomask=
audioall=
audiomux=
See Sound-FAQ for a detailed description.
remap, card, radio and pll accept up to four comma-separated arguments
(for multiple boards).
tuner.o
The tuner driver. You need this unless you want to use only
with a camera or external tuner ...
insmod args:
debug=1 print some debug info to the syslog
type=n type of the tuner chip. n as follows:
see CARDLIST for a complete list.
pal=[bdgil] select PAL variant (used for some tuners
only, important for the audio carrier).
tvaudio.o
new, experimental module which is supported to provide a single
driver for all simple i2c audio control chips (tda/tea*).
insmod args:
tda8425 = 1 enable/disable the support for the
tda9840 = 1 various chips.
tda9850 = 1 The tea6300 can't be autodetected and is
tda9855 = 1 therefore off by default, if you have
tda9873 = 1 this one on your card (STB uses these)
tda9874a = 1 you have to enable it explicitly.
tea6300 = 0 The two tda985x chips use the same i2c
tea6420 = 1 address and can't be disturgished from
pic16c54 = 1 each other, you might have to disable
the wrong one.
debug = 1 print debug messages
insmod args for tda9874a:
tda9874a_SIF=1/2 select sound IF input pin (1 or 2)
(default is pin 1)
tda9874a_AMSEL=0/1 auto-mute select for NICAM (default=0)
Please read note 3 below!
tda9874a_STD=n select TV sound standard (0..8):
0 - A2, B/G
1 - A2, M (Korea)
2 - A2, D/K (1)
3 - A2, D/K (2)
4 - A2, D/K (3)
5 - NICAM, I
6 - NICAM, B/G
7 - NICAM, D/K (default)
8 - NICAM, L
Note 1: tda9874a supports both tda9874h (old) and tda9874a (new) chips.
Note 2: tda9874h/a and tda9875 (which is supported separately by
tda9875.o) use the same i2c address so both modules should not be
used at the same time.
Note 3: Using tda9874a_AMSEL option depends on your TV card design!
AMSEL=0: auto-mute will switch between NICAM sound
and the sound on 1st carrier (i.e. FM mono or AM).
AMSEL=1: auto-mute will switch between NICAM sound
and the analog mono input (MONOIN pin).
If tda9874a decoder on your card has MONOIN pin not connected, then
use only tda9874_AMSEL=0 or don't specify this option at all.
For example:
card=65 (FlyVideo 2000S) - set AMSEL=1 or AMSEL=0
card=72 (Prolink PV-BT878P rev.9B) - set AMSEL=0 only
msp3400.o
The driver for the msp34xx sound processor chips. If you have a
stereo card, you probably want to insmod this one.
insmod args:
debug=1/2 print some debug info to the syslog,
2 is more verbose.
simple=1 Use the "short programming" method. Newer
msp34xx versions support this. You need this
for dbx stereo. Default is on if supported by
the chip.
once=1 Don't check the TV-stations Audio mode
every few seconds, but only once after
channel switches.
amsound=1 Audio carrier is AM/NICAM at 6.5 Mhz. This
should improve things for french people, the
carrier autoscan seems to work with FM only...
tea6300.o - OBSOLETE (use tvaudio instead)
The driver for the tea6300 fader chip. If you have a stereo
card and the msp3400.o doesn't work, you might want to try this
one. This chip is seen on most STB TV/FM cards (usually from
Gateway OEM sold surplus on auction sites).
insmod args:
debug=1 print some debug info to the syslog.
tda8425.o - OBSOLETE (use tvaudio instead)
The driver for the tda8425 fader chip. This driver used to be
part of bttv.c, so if your sound used to work but does not
anymore, try loading this module.
insmod args:
debug=1 print some debug info to the syslog.
tda985x.o - OBSOLETE (use tvaudio instead)
The driver for the tda9850/55 audio chips.
insmod args:
debug=1 print some debug info to the syslog.
chip=9850/9855 set the chip type.
Documentation/video4linux/bttv/MAKEDEV deleted 100644 → 0
View file @ 2e97d6d3
#!/bin/bash
function makedev () {
for dev in 0 1 2 3; do
echo "/dev/$1$dev: char 81 $[ $2 + $dev ]"
rm -f /dev/$1$dev
mknod /dev/$1$dev c 81 $[ $2 + $dev ]
chmod 666 /dev/$1$dev
done
# symlink for default device
rm -f /dev/$1
ln -s /dev/${1}0 /dev/$1
}
# see http://linux.bytesex.org/v4l2/API.html
echo "*** new device names ***"
makedev video 0
makedev radio 64
makedev vbi 224
#echo "*** old device names (for compatibility only) ***"
#makedev bttv 0
#makedev bttv-fm 64
#makedev bttv-vbi 224
Documentation/video4linux/bttv/Modprobe.conf deleted 100644 → 0
View file @ 2e97d6d3
# i2c
alias char-major-89 i2c-dev
options i2c-core i2c_debug=1
options i2c-algo-bit bit_test=1
# bttv
alias char-major-81 videodev
alias char-major-81-0 bttv
options bttv card=2 radio=1
options tuner debug=1
Documentation/video4linux/bttv/Modules.conf deleted 100644 → 0
View file @ 2e97d6d3
# For modern kernels (2.6 or above), this belongs in /etc/modprobe.d/*.conf
# For for 2.4 kernels or earlier, this belongs in /etc/modules.conf.
# i2c
alias char-major-89 i2c-dev
options i2c-core i2c_debug=1
options i2c-algo-bit bit_test=1
# bttv
alias char-major-81 videodev
alias char-major-81-0 bttv
options bttv card=2 radio=1
options tuner debug=1
Documentation/video4linux/bttv/PROBLEMS deleted 100644 → 0
View file @ 2e97d6d3
- Start capturing by pressing "c" or by selecting it via a menu!
- Start capturing by pressing "c" or by selecting it via a menu!!!
- The memory of some S3 cards is not recognized right:
First of all, if you are not using XFree-3.2 or newer, upgrade AT LEAST to
XFree-3.2A! This solved the problem for most people.
Start up X11 like this: "XF86_S3 -probeonly" and write down where the
linear frame buffer is.
If it is different to the address found by bttv install bttv like this:
"insmod bttv vidmem=0xfb0"
if the linear frame buffer is at 0xfb000000 (i.e. omit the last 5 zeros!)
Some S3 cards even take up 64MB of memory but only report 32MB to the BIOS.
If this 64MB area overlaps the IO memory of the Bt848 you also have to
remap this. E.g.: insmod bttv vidmem=0xfb0 remap=0xfa0
If the video memory is found at the right place and there are no address
conflicts but still no picture (or the computer even crashes),
try disabling features of your PCI chipset in the BIOS setup.
Frank Kapahnke <frank@kapahnke.prima.ruhr.de> also reported that problems
with his S3 868 went away when he upgraded to XFree 3.2.
- I still only get a black picture with my S3 card!
Even with XFree-3.2A some people have problems with their S3 cards
(mostly with Trio 64 but also with some others)
Get the free demo version of Accelerated X from www.xinside.com and try
bttv with it. bttv seems to work with most S3 cards with Accelerated X.
Since I do not know much (better make that almost nothing) about VGA card
programming I do not know the reason for this.
Looks like XFree does something different when setting up the video memory?
Maybe somebody can enlighten me?
Would be nice if somebody could get this to work with XFree since
Accelerated X costs more than some of the grabber cards ...
Better linear frame buffer support for S3 cards will probably be in
XFree 4.0.
- Grabbing is not switched off when changing consoles with XFree.
That's because XFree and some AcceleratedX versions do not send unmap
events.
- Some popup windows (e.g. of the window manager) are not refreshed.
Disable backing store by starting X with the option "-bs"
- When using 32 bpp in XFree or 24+8bpp mode in AccelX 3.1 the system
can sometimes lock up if you use more than 1 bt848 card at the same time.
You will always get pixel errors when e.g. using more than 1 card in full
screen mode. Maybe we need something faster than the PCI bus ...
- Some S3 cards and the Matrox Mystique will produce pixel errors with
full resolution in 32-bit mode.
- Some video cards have problems with Accelerated X 4.1
Documentation/video4linux/bttv/README deleted 100644 → 0
View file @ 2e97d6d3
Release notes for bttv
======================
You'll need at least these config options for bttv:
CONFIG_I2C=m
CONFIG_I2C_ALGOBIT=m
CONFIG_VIDEO_DEV=m
The latest bttv version is available from http://bytesex.org/bttv/
Make bttv work with your card
-----------------------------
Just try "modprobe bttv" and see if that works.
If it doesn't bttv likely could not autodetect your card and needs some
insmod options. The most important insmod option for bttv is "card=n"
to select the correct card type. If you get video but no sound you've
very likely specified the wrong (or no) card type. A list of supported
cards is in CARDLIST.bttv
If bttv takes very long to load (happens sometimes with the cheap
cards which have no tuner), try adding this to your modules.conf:
options i2c-algo-bit bit_test=1
For the WinTV/PVR you need one firmware file from the driver CD:
hcwamc.rbf. The file is in the pvr45xxx.exe archive (self-extracting
zip file, unzip can unpack it). Put it into the /etc/pvr directory or
use the firm_altera=<path> insmod option to point the driver to the
location of the file.
If your card isn't listed in CARDLIST.bttv or if you have trouble making
audio work, you should read the Sound-FAQ.
Autodetecting cards
-------------------
bttv uses the PCI Subsystem ID to autodetect the card type. lspci lists
the Subsystem ID in the second line, looks like this:
00:0a.0 Multimedia video controller: Brooktree Corporation Bt878 (rev 02)
Subsystem: Hauppauge computer works Inc. WinTV/GO
Flags: bus master, medium devsel, latency 32, IRQ 5
Memory at e2000000 (32-bit, prefetchable) [size=4K]
only bt878-based cards can have a subsystem ID (which does not mean
that every card really has one). bt848 cards can't have a Subsystem
ID and therefore can't be autodetected. There is a list with the ID's
in bttv-cards.c (in case you are intrested or want to mail patches
with updates).
Still doesn't work?
-------------------
I do NOT have a lab with 30+ different grabber boards and a
PAL/NTSC/SECAM test signal generator at home, so I often can't
reproduce your problems. This makes debugging very difficult for me.
If you have some knowledge and spare time, please try to fix this
yourself (patches very welcome of course...) You know: The linux
slogan is "Do it yourself".
There is a mailing list: linux-media@vger.kernel.org
http://vger.kernel.org/vger-lists.html#linux-media
If you have trouble with some specific TV card, try to ask there
instead of mailing me directly. The chance that someone with the
same card listens there is much higher...
For problems with sound: There are a lot of different systems used
for TV sound all over the world. And there are also different chips
which decode the audio signal. Reports about sound problems ("stereo
does'nt work") are pretty useless unless you include some details
about your hardware and the TV sound scheme used in your country (or
at least the country you are living in).
Finally: If you mail some patches for bttv around the world (to
linux-kernel/Alan/Linus/...), please Cc: me.
Have fun with bttv,
Gerd
--
Gerd Knorr <kraxel@bytesex.org>
Documentation/video4linux/bttv/README.WINVIEW deleted 100644 → 0
View file @ 2e97d6d3
Support for the Leadtek WinView 601 TV/FM by Jon Tombs <jon@gte.esi.us.es>
This card is basically the same as all the rest (Bt484A, Philips tuner),
the main difference is that they have attached a programmable attenuator to 3
GPIO lines in order to give some volume control. They have also stuck an
infra-red remote control decoded on the board, I will add support for this
when I get time (it simple generates an interrupt for each key press, with
the key code is placed in the GPIO port).
I don't yet have any application to test the radio support. The tuner
frequency setting should work but it is possible that the audio multiplexer
is wrong. If it doesn't work, send me email.
- No Thanks to Leadtek they refused to answer any questions about their
hardware. The driver was written by visual inspection of the card. If you
use this driver, send an email insult to them, and tell them you won't
continue buying their hardware unless they support Linux.
- Little thanks to Princeton Technology Corp (http://www.princeton.com.tw)
who make the audio attenuator. Their publicly available data-sheet available
on their web site doesn't include the chip programming information! Hidden
on their server are the full data-sheets, but don't ask how I found it.
To use the driver I use the following options, the tuner and pll settings might
be different in your country
insmod videodev
insmod i2c scan=1 i2c_debug=0 verbose=0
insmod tuner type=1 debug=0
insmod bttv pll=1 radio=1 card=17
Documentation/video4linux/bttv/README.freeze deleted 100644 → 0
View file @ 2e97d6d3
If the box freezes hard with bttv ...
=====================================
It might be a bttv driver bug. It also might be bad hardware. It also
might be something else ...
Just mailing me "bttv freezes" isn't going to help much. This README
has a few hints how you can help to pin down the problem.
bttv bugs
---------
If some version works and another doesn't it is likely to be a driver
bug. It is very helpful if you can tell where exactly it broke
(i.e. the last working and the first broken version).
With a hard freeze you probably doesn't find anything in the logfiles.
The only way to capture any kernel messages is to hook up a serial
console and let some terminal application log the messages. /me uses
screen. See Documentation/serial-console.txt for details on setting
up a serial console.
Read Documentation/oops-tracing.txt to learn how to get any useful
information out of a register+stack dump printed by the kernel on
protection faults (so-called "kernel oops").
If you run into some kind of deadlock, you can try to dump a call trace
for each process using sysrq-t (see Documentation/sysrq.txt).
This way it is possible to figure where *exactly* some process in "D"
state is stuck.
I've seen reports that bttv 0.7.x crashes whereas 0.8.x works rock solid
for some people. Thus probably a small buglet left somewhere in bttv
0.7.x. I have no idea where exactly, it works stable for me and a lot of
other people. But in case you have problems with the 0.7.x versions you
can give 0.8.x a try ...
hardware bugs
-------------
Some hardware can't deal with PCI-PCI transfers (i.e. grabber => vga).
Sometimes problems show up with bttv just because of the high load on
the PCI bus. The bt848/878 chips have a few workarounds for known
incompatibilities, see README.quirks.
Some folks report that increasing the pci latency helps too,
althrought I'm not sure whenever this really fixes the problems or
only makes it less likely to happen. Both bttv and btaudio have a
insmod option to set the PCI latency of the device.
Some mainboard have problems to deal correctly with multiple devices
doing DMA at the same time. bttv + ide seems to cause this sometimes,
if this is the case you likely see freezes only with video and hard disk
access at the same time. Updating the IDE driver to get the latest and
greatest workarounds for hardware bugs might fix these problems.
other
-----
If you use some binary-only yunk (like nvidia module) try to reproduce
the problem without.
IRQ sharing is known to cause problems in some cases. It works just
fine in theory and many configurations. Neverless it might be worth a
try to shuffle around the PCI cards to give bttv another IRQ or make
it share the IRQ with some other piece of hardware. IRQ sharing with
VGA cards seems to cause trouble sometimes. I've also seen funny
effects with bttv sharing the IRQ with the ACPI bridge (and
apci-enabled kernel).
Documentation/video4linux/bttv/README.quirks deleted 100644 → 0
View file @ 2e97d6d3
Below is what the bt878 data book says about the PCI bug compatibility
modes of the bt878 chip.
The triton1 insmod option sets the EN_TBFX bit in the control register.
The vsfx insmod option does the same for EN_VSFX bit. If you have
stability problems you can try if one of these options makes your box
work solid.
drivers/pci/quirks.c knows about these issues, this way these bits are
enabled automagically for known-buggy chipsets (look at the kernel
messages, bttv tells you).
HTH,
Gerd
---------------------------- cut here --------------------------
Normal PCI Mode
---------------
The PCI REQ signal is the logical-or of the incoming function requests.
The inter-nal GNT[0:1] signals are gated asynchronously with GNT and
demultiplexed by the audio request signal. Thus the arbiter defaults to
the video function at power-up and parks there during no requests for
bus access. This is desirable since the video will request the bus more
often. However, the audio will have highest bus access priority. Thus
the audio will have first access to the bus even when issuing a request
after the video request but before the PCI external arbiter has granted
access to the Bt879. Neither function can preempt the other once on the
bus. The duration to empty the entire video PCI FIFO onto the PCI bus is
very short compared to the bus access latency the audio PCI FIFO can
tolerate.
430FX Compatibility Mode
------------------------
When using the 430FX PCI, the following rules will ensure
compatibility:
(1) Deassert REQ at the same time as asserting FRAME.
(2) Do not reassert REQ to request another bus transaction until after
finish-ing the previous transaction.
Since the individual bus masters do not have direct control of REQ, a
simple logical-or of video and audio requests would violate the rules.
Thus, both the arbiter and the initiator contain 430FX compatibility
mode logic. To enable 430FX mode, set the EN_TBFX bit as indicated in
Device Control Register on page 104.
When EN_TBFX is enabled, the arbiter ensures that the two compatibility
rules are satisfied. Before GNT is asserted by the PCI arbiter, this
internal arbiter may still logical-or the two requests. However, once
the GNT is issued, this arbiter must lock in its decision and now route
only the granted request to the REQ pin. The arbiter decision lock
happens regardless of the state of FRAME because it does not know when
FRAME will be asserted (typically - each initiator will assert FRAME on
the cycle following GNT). When FRAME is asserted, it is the initiator s
responsibility to remove its request at the same time. It is the
arbiters responsibility to allow this request to flow through to REQ and
not allow the other request to hold REQ asserted. The decision lock may
be removed at the end of the transaction: for example, when the bus is
idle (FRAME and IRDY). The arbiter decision may then continue
asynchronously until GNT is again asserted.
Interfacing with Non-PCI 2.1 Compliant Core Logic
-------------------------------------------------
A small percentage of core logic devices may start a bus transaction
during the same cycle that GNT is de-asserted. This is non PCI 2.1
compliant. To ensure compatibility when using PCs with these PCI
controllers, the EN_VSFX bit must be enabled (refer to Device Control
Register on page 104). When in this mode, the arbiter does not pass GNT
to the internal functions unless REQ is asserted. This prevents a bus
transaction from starting the same cycle as GNT is de-asserted. This
also has the side effect of not being able to take advantage of bus
parking, thus lowering arbitration performance. The Bt879 drivers must
query for these non-compliant devices, and set the EN_VSFX bit only if
required.
Documentation/video4linux/bttv/Sound-FAQ deleted 100644 → 0
View file @ 2e97d6d3
bttv and sound mini howto
=========================
There are a lot of different bt848/849/878/879 based boards available.
Making video work often is not a big deal, because this is handled
completely by the bt8xx chip, which is common on all boards. But
sound is handled in slightly different ways on each board.
To handle the grabber boards correctly, there is a array tvcards[] in
bttv-cards.c, which holds the information required for each board.
Sound will work only, if the correct entry is used (for video it often
makes no difference). The bttv driver prints a line to the kernel
log, telling which card type is used. Like this one:
bttv0: model: BT848(Hauppauge old) [autodetected]
You should verify this is correct. If it isn't, you have to pass the
correct board type as insmod argument, "insmod bttv card=2" for
example. The file CARDLIST has a list of valid arguments for card.
If your card isn't listed there, you might check the source code for
new entries which are not listed yet. If there isn't one for your
card, you can check if one of the existing entries does work for you
(just trial and error...).
Some boards have an extra processor for sound to do stereo decoding
and other nice features. The msp34xx chips are used by Hauppauge for
example. If your board has one, you might have to load a helper
module like msp3400.o to make sound work. If there isn't one for the
chip used on your board: Bad luck. Start writing a new one. Well,
you might want to check the video4linux mailing list archive first...
Of course you need a correctly installed soundcard unless you have the
speakers connected directly to the grabber board. Hint: check the
mixer settings too. ALSA for example has everything muted by default.
How sound works in detail
=========================
Still doesn't work? Looks like some driver hacking is required.
Below is a do-it-yourself description for you.
The bt8xx chips have 32 general purpose pins, and registers to control
these pins. One register is the output enable register
(BT848_GPIO_OUT_EN), it says which pins are actively driven by the
bt848 chip. Another one is the data register (BT848_GPIO_DATA), where
you can get/set the status if these pins. They can be used for input
and output.
Most grabber board vendors use these pins to control an external chip
which does the sound routing. But every board is a little different.
These pins are also used by some companies to drive remote control
receiver chips. Some boards use the i2c bus instead of the gpio pins
to connect the mux chip.
As mentioned above, there is a array which holds the required
information for each known board. You basically have to create a new
line for your board. The important fields are these two:
struct tvcard
{
[ ... ]
u32 gpiomask;
u32 audiomux[6]; /* Tuner, Radio, external, internal, mute, stereo */
};
gpiomask specifies which pins are used to control the audio mux chip.
The corresponding bits in the output enable register
(BT848_GPIO_OUT_EN) will be set as these pins must be driven by the
bt848 chip.
The audiomux[] array holds the data values for the different inputs
(i.e. which pins must be high/low for tuner/mute/...). This will be
written to the data register (BT848_GPIO_DATA) to switch the audio
mux.
What you have to do is figure out the correct values for gpiomask and
the audiomux array. If you have Windows and the drivers four your
card installed, you might to check out if you can read these registers
values used by the windows driver. A tool to do this is available
from ftp://telepresence.dmem.strath.ac.uk/pub/bt848/winutil, but it
does'nt work with bt878 boards according to some reports I received.
Another one with bt878 support is available from
http://btwincap.sourceforge.net/Files/btspy2.00.zip
You might also dig around in the *.ini files of the Windows applications.
You can have a look at the board to see which of the gpio pins are
connected at all and then start trial-and-error ...
Starting with release 0.7.41 bttv has a number of insmod options to
make the gpio debugging easier:
bttv_gpio=0/1 enable/disable gpio debug messages
gpiomask=n set the gpiomask value
audiomux=i,j,... set the values of the audiomux array
audioall=a set the values of the audiomux array (one
value for all array elements, useful to check
out which effect the particular value has).
The messages printed with bttv_gpio=1 look like this:
bttv0: gpio: en=00000027, out=00000024 in=00ffffd8 [audio: off]
en = output _en_able register (BT848_GPIO_OUT_EN)
out = _out_put bits of the data register (BT848_GPIO_DATA),
i.e. BT848_GPIO_DATA & BT848_GPIO_OUT_EN
in = _in_put bits of the data register,
i.e. BT848_GPIO_DATA & ~BT848_GPIO_OUT_EN
Other elements of the tvcards array
===================================
If you are trying to make a new card work you might find it useful to
know what the other elements in the tvcards array are good for:
video_inputs - # of video inputs the card has
audio_inputs - historical cruft, not used any more.
tuner - which input is the tuner
svhs - which input is svhs (all others are labeled composite)
muxsel - video mux, input->registervalue mapping
pll - same as pll= insmod option
tuner_type - same as tuner= insmod option
*_modulename - hint whenever some card needs this or that audio
module loaded to work properly.
has_radio - whenever this TV card has a radio tuner.
no_msp34xx - "1" disables loading of msp3400.o module
no_tda9875 - "1" disables loading of tda9875.o module
needs_tvaudio - set to "1" to load tvaudio.o module
If some config item is specified both from the tvcards array and as
insmod option, the insmod option takes precedence.
Good luck,
Gerd
PS: If you have a new working entry, mail it to me.
--
Gerd Knorr <kraxel@bytesex.org>
Documentation/video4linux/bttv/Specs deleted 100644 → 0
View file @ 2e97d6d3
Philips http://www.Semiconductors.COM/pip/
Conexant http://www.conexant.com/
Micronas http://www.micronas.com/en/home/index.html
Documentation/video4linux/bttv/THANKS deleted 100644 → 0
View file @ 2e97d6d3
Many thanks to:
- Markus Schroeder <schroedm@uni-duesseldorf.de> for information on the Bt848
and tuner programming and his control program xtvc.
- Martin Buck <martin-2.buck@student.uni-ulm.de> for his great Videotext
package.
- Gerd Knorr <kraxel@cs.tu-berlin.de> for the MSP3400 support and the modular
I2C, tuner, ... support.
- MATRIX Vision for giving us 2 cards for free, which made support of
single crystal operation possible.
- MIRO for providing a free PCTV card and detailed information about the
components on their cards. (E.g. how the tuner type is detected)
Without their card I could not have debugged the NTSC mode.
- Hauppauge for telling how the sound input is selected and what components
they do and will use on their radio cards.
Also many thanks for faxing me the FM1216 data sheet.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7