Re: Media controller: sysfs vs ioctl
Hans Verkuil schrieb: Hi all, I've started this as a new thread to prevent polluting the discussions of the media controller as a concept. First of all, I have no doubt that everything that you can do with an ioctl, you can also do with sysfs and vice versa. That's not the problem here. The problem is deciding which approach is the best. Is it really a good idea to create a dependency to some virtual file system which may go away in future? From time to time some of those seem to go away, for example devfs. Is it really unavoidable to have something in sysfs, something which is really not possible with ioctls? And do you really want to depend on sysfs developers? --Winfried -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch review 6/6] radio-mr800: redesign radio->users counter
Alexey Klimov schrieb: On Sat, Aug 8, 2009 at 10:01 PM, Trent Piepho wrote: On Sat, 8 Aug 2009, Alexey Klimov wrote: Redesign radio->users counter. Don't allow more that 5 users on radio in Why? Well, v4l2 specs says that multiple opens are optional. Honestly, i think that five userspace applications open /dev/radio is enough. Btw, if too many userspace applications opened radio that means that something wrong happened in userspace. And driver can handle such situation by disallowing new open calls(returning EBUSY). I can't imagine user that runs more than five mplayers or gnomeradios, or kradios and so on. Am i totally wrong here? Thanks. "I can't imagine.." Funny answer, reminds at the 640kB limit of old computers.. :) But if there's no real technical restriction, the driver should not restrict access a device at all. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Why is the old DVB ML still alive?
Why is the old dvb (linux-dvb) mailing list still alive? One of the arguments migrating all dvb related stuff to this combined ml was to reduce overhead. But in fact some information might be lost now, since not everybody will look at both ML's. Wouldn't it be a good idea to close the old ml now / is this foreseen at all? --Winfried -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ivtv && Radio Data System (RDS) - is there something planned/already available
Edouard Lafargue wrote: On Fri, Jun 19, 2009 at 1:43 PM, Hans Verkuil wrote: On Friday 19 June 2009 13:36:49 wk wrote: Is there anything planned/ongoing to support Radio Data System (RDS) with ivtv supported cards? Would be quite helpful for analogue radio channel scanning and finding the matching channel names. Is there something out to be tested? As far as I know there are no ivtv-based cards with RDS functionality. If you have one that can do RDS under Windows, then please let me know and I can take a look. A workaround can be to use a 10$ USB radio with RDS support and use it as a secondary (silent) tuner for doing the scanning operations in the background, so that you can have a fully up to date radio stations list all the time without impacting the listening of your main radio tuner - works very well! Well, the idea was to integrate this into a channel scanning tool. So this wouldnt be an option. Winfried -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ivtv && Radio Data System (RDS) - is there something planned/already available
Hans Verkuil schrieb: On Friday 19 June 2009 13:36:49 wk wrote: Is there anything planned/ongoing to support Radio Data System (RDS) with ivtv supported cards? Would be quite helpful for analogue radio channel scanning and finding the matching channel names. Is there something out to be tested? As far as I know there are no ivtv-based cards with RDS functionality. Ok, if the hardware doesnt support it, further questions are meaningless.. thanks, Winfried -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
ivtv && Radio Data System (RDS) - is there something planned/already available
Is there anything planned/ongoing to support Radio Data System (RDS) with ivtv supported cards? Would be quite helpful for analogue radio channel scanning and finding the matching channel names. Is there something out to be tested? thanks, Winfried -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: w_scan 20090502, why is the new country code necessary, its breaking my systems
Hello Jelle, > My w_scan version 20081106 stopped working on my Debian system. I had > the following errors: > ERROR: Sorry - i couldn't get any working frequency/transponder > > So I first checked if there was a wscan update. No reception for some reason - probably the new version will show the same result. > I had to make a new argument line: > ~/.wscan/wscan -t 3 -A 1 -E 0 -O 0 -c NL -X tzap > ~/.wscan/channels.conf "-A 1" is wrong for you, please omitt this one, it's used outside Europe only. "-O 0" is default anyway, not needed > This is very troubling for me because I must have a scan command that > works in complete Europa and not in one country. This is because I have > traveling systems that need to scan for channels on every stop. > > Why :-( please explain and try to fix this regression that a country > code is needed? w_scan tends to be used now to be used also in other countries - with different settings - frequency lists - frequency offsets from center frequency - Symbolrates - channel bandwidths - Modulations ( QAM_128 for example in FI, QAM_64 and QAM_256 otherwise ) At the beginning w_scan was made to work in Germany only. But with the time more and more additions were made and at some point one has to find a compromise. Either prolong scanning time to be endless, omitt new features or change command line options. If you need the some behaviour working in many european countries, you may simply use "-c DE". It will give nearly the same result as the old versions. > I was hoping for auto signal strength detection and automatic filtering > depending on the signal strength to remove duplicated channels from > different broadcast towers.. what work is being done to realize this, > and can I help by donating resources? As soon we have dvb drivers which give some reliable and *comparable* signal strength information signal information *across all frontends* this would be possible, not earlier. But i guess it will never happen. Best Regards, Winfried -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge HVR-1500 (aka HP RM436AA#ABA)
Benster & Jeremy wrote: The patch works perfectly. No indicator light, but 28 channels with stronger signal than mce! Thanks again! Ben -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Can you pls give some hint wether w_scan now also works with your card? --winfried -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [question] atsc and api v5
Devin Heitmueller wrote:
On Tue, Mar 24, 2009 at 12:35 PM, wk wrote:
While trying to update an application to API v5 some question arised.
Which type of "delivery_system" should be set for ATSC?
says...
SYS_DVBC_ANNEX_AC, <- european DVB-C
SYS_DVBC_ANNEX_B, <- american ATSC QAM
..
SYS_ATSC, <- oops, here we have ATSC again, cable and terrestrial not
named? Is this VSB *only*?
Which one should i choose, "SYS_ATSC" for both (VSB and QAM),
or should i choose SYS_DVBC_ANNEX_B for ATSC cable and SYS_ATSC for VSB?
thanks,
Winfried
I'm pretty sure it's SYS_ATSC for both VSB and QAM.
Devin
Meanwhile i think this is the answer..
dvb-core/dvb_frontend.c line 1076
/* Synchronise the legacy tuning parameters into the cache, so that
demodulator
* drivers can use a single set_frontend tuning function, regardless of
whether
* it's being used for the legacy or new API, reducing code and complexity.
*/
static void dtv_property_cache_sync(struct dvb_frontend *fe,
struct dvb_frontend_parameters *p)
{
.
switch (fe->ops.info.type) {
..
case FE_ATSC:
c->modulation = p->u.vsb.modulation;
if ((c->modulation == VSB_8) || (c->modulation == VSB_16))
c->delivery_system = SYS_ATSC;
else
c->delivery_system = SYS_DVBC_ANNEX_B; <- QAM_64
and QAM_256 here
break;
That means the naming is completely misleading here.
I have to choose SYS_DVBC_ANNEX_B for ATSC QAM, but ATSC VSB needs SYS_ATSC.
Winfried
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[question] atsc and api v5
While trying to update an application to API v5 some question arised. Which type of "delivery_system" should be set for ATSC? says... SYS_DVBC_ANNEX_AC, <- european DVB-C SYS_DVBC_ANNEX_B, <- american ATSC QAM .. SYS_ATSC, <- oops, here we have ATSC again, cable and terrestrial not named? Is this VSB *only*? Which one should i choose, "SYS_ATSC" for both (VSB and QAM), or should i choose SYS_DVBC_ANNEX_B for ATSC cable and SYS_ATSC for VSB? thanks, Winfried -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SNR status for demods
I have updated my compiled list of the various demods and how they currently report SNR info (including feedback from people in the last round). http://www.devinheitmueller.com/snr.txt What about signal strength and BER readout in parallel for each device listed here? Needs the same docs and would not add too much work.. tda10021: MSE[7..0] (= reg 0x18 ) "Mean Square Error of the demodulated output signal. MSE can be used as a representation of the signal quality." u8 quality = ~tda10021_readreg(state, 0x18); *snr = (quality << 8) | quality; ves1820:the same. tda10023: seems to be the same. (no info, but chip is very close to tda10021) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add new frequency table for Strasbourg, France
Benjamin Zores schrieb: wk wrote: Then there must be something ``wrong'' with `w_scan' making incorrect assumptions about the data which it's parsing. No - i do not think so. All of the frequencies found are with 166kHz offset. w_scan does not use any of these 166k offsets, that means this frequency data was transmitted as exactly such a number in some NIT w_scan parsed. w_scan calculates DVB-T center freqs as "center freq = (30600 + channel * 800) Hz" for this range. And NIT parsing is the same as dvbscan. What has disturbed me is how this offset has been applied across the board by `w_scan', Again, w_scan does not use these offsets. Again, I've added these offsets to w_scan results as it was written in linuxtv wiki. Ben If you manually edited the frequencies, we can stop searching here. This is definitely wrong. If somebody wrote something like this to linuxtv wiki, we should remove that lines. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add new frequency table for Strasbourg, France
Then there must be something ``wrong'' with `w_scan' making incorrect assumptions about the data which it's parsing. No - i do not think so. All of the frequencies found are with 166kHz offset. w_scan does not use any of these 166k offsets, that means this frequency data was transmitted as exactly such a number in some NIT w_scan parsed. w_scan calculates DVB-T center freqs as "center freq = (30600 + channel * 800) Hz" for this range. And NIT parsing is the same as dvbscan. What has disturbed me is how this offset has been applied across the board by `w_scan', Again, w_scan does not use these offsets. Some dvbsnoop output as suggested and additional some scan with service names (either dvbscan or w_scan), vdr channels.conf would be fine, would really help to see whats going on here. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add new frequency table for Strasbourg, France
I have some table frequency list here: http://www.tvnt.net/V2/pages/342/medias/pro-bo-doc-tk-frequences_tnt.pdf See the "Canal" array, page 20 for "Strasbourg". I don't know how to determine transponders frequencies from this list. Please find also the remark inside the file: "(9) The frequency in MHz channel n is defined as: center frequency = 306 + 8 n + 0.166 d, n is between 21 and 69, d can take the values -1, 0, 1, 2 or 3 depending on the needs planning." -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add new frequency table for Strasbourg, France
Benjamin Zores wrote: BOUWSMA Barry wrote: First, every frequency is given an offset from the nominal centre frequency of the 8MHz envelope. I am aware this is common in the UK where the switchover is happening gradually so as not to interfere with adjacent analogue services, and I also know that last I checked, the number of french analogue services I could receive weakly had dropped, but at least one was still visible. These were discovered through w_scan application. +T 482167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE If that information was found by w_scan, that information was found by parsing the NIT ot this channel. Current w_scan doesn't use +/-167k offsets. Since in Germany no transmitter uses any freq offsets, the information comes from the French one. And for France finding that freq offsets is quite normal. --wk -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
Devin Heitmueller schrieb: On Fri, Mar 13, 2009 at 6:27 PM, VDR User wrote: Just wanted to comment that I'm glad there is a lot of interest in this. I've heard endless talk & confusion on the user end over the years as to the accuracy of the values, or in some cases (as with Genpix adapters for example) where you don't seem to get any useful information. Of course making it really hard for people who are trying to aim dishes and the like in the case of dvb-s*. A quick question about implimenting this though.. What's the most difficult component? Hello, There are basically two "difficult components" 1. Getting everyone to agree on a standard representation for the field, and how to represent certain error conditions (such as when a demod doesn't support SNR, or when it cannot return a valid value at a given time). Its just straightforward as described in DVB API, chapters 2.2.3 FE READ STATUS 2.2.4 FE READ BER 2.2.5 FE READ SNR 2.2.6 FE READ SIGNAL STRENGTH 2.2.7 FE READ UNCORRECTED BLOCKS if ioctl suceeds with valid data: 0, if not one of EBADFno valid file descriptor. EFAULT error condition ENOSIGNAL not yet, i have no signal.. ENOSYS not supported by device. 2. Converting all the drivers to the agreed-upon format. For some drivers this is relatively easy as we have specs available for how the SNR is represented. For others, the value displayed is entirely reverse engineered so the current representations are completely arbitrary. Devin Since a lot of frontends have no proper docs, probably providing the signal strength unit with a second ioctl could make sense here. a.u. arbitrary units, not exactly known or not perfectly working dBµV comparable trough all devices, but probably not possible for all percent technical not understandable, percent relative to what? Assumes that there is a optimum/hard limit of 100% which is not the case. Showing values as human readings is on the app side, so hex output in raw numbers are just fine here. No change needed. -- Winfried -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dvb-api: update documentation, chapter1 (Resubmit)
Mauro Carvalho Chehab schrieb:
Hi wk,
Let's commit what we currently have. Could you please re-submit the patch
again, this time providing a proper description, and your SOB?
Cheers,
Mauro.
The attached patch provides the following changes to DVB API:
- files changed
- dvbapi.tex
- intro.tex
- title.tex
- change page format from "twosided book" to "onesided book" to improve
readability
- fix several latex compiling warnings "Overfull \hbox" due to too long
lines.
- replace in chapter 1 all occurrencies of "DVB PCI card" with "DVB device"
- change First Page:
- add "and The Linux DVB developers" to Copyright
- add "2008, 2009 www.linuxtv.org" to Copyright
- change version and date to "22/02/2009 Version 1.1.0"
- change Chapter 1, Section 1.2 History:
- remove line that Convergence is maintainer of doc, since in fact
linuxtv.org is currently maintaining it.
- remove line "Together with the LinuxTV community (i.e. you, the
reader of this document),
the Linux DVB API will be constantly reviewed and
improved."
- remove line "With the Linux driver for the Siemens/Hauppauge DVB
PCI card Convergence
provides a first implementation of the Linux DVB API"
- add comment about neither completed, nor implemented DVB API v4
- add comment about being project independent and non-profit
- add comment describing digital part only and cross-reference to
V4L2 API on linuxtv
- add comment about need for API extension for newer DTV standards
- add comment about Multiproto and S2API and decision on plumbers
conference 2k8
- add comment about version now called v5
- change Chapter 1, Section 1.3 Overview:
- change "MPEG picture and sound decoding" to "MPEG video and
audio decoding"
- change Chapter 1, Section 1.4 Linux DVB Devices
- remove reference to no longer used devfs
- change Chapter 1, Section 1.5 API include files
- fix typo: "to support different API version" -> "to support
different API versions"
- add "Since API version 5 an API command for quering API version
also exists,
allowing user space applications to detect API
version during runtime"
=> see also:
http://www.linuxtv.org/news.php?entry=2008-09-23.mchehab
"Adding an API command for querying DVB version, to
allow an easier detection by userspaceapplications"
Signed-off-by: Winfried Koehler
diff -Nurp v4l-dvb-17554cc18063/dvb-spec/dvbapi/dvbapi.tex
v4l-dvb-17554cc18063_1/dvb-spec/dvbapi/dvbapi.tex
--- v4l-dvb-17554cc18063/dvb-spec/dvbapi/dvbapi.tex2009-02-23
16:26:38.0 +0100
+++ v4l-dvb-17554cc18063_1/dvb-spec/dvbapi/dvbapi.tex2009-02-26
18:40:35.008186330 +0100
@@ -1,4 +1,4 @@
-\documentclass[a4paper,10pt]{book}
+\documentclass[a4paper,10pt,oneside]{book}
\usepackage[dvips,colorlinks=true]{hyperref}
\usepackage{times}
diff -Nurp v4l-dvb-17554cc18063/dvb-spec/dvbapi/intro.tex
v4l-dvb-17554cc18063_1/dvb-spec/dvbapi/intro.tex
--- v4l-dvb-17554cc18063/dvb-spec/dvbapi/intro.tex2009-02-23
16:26:38.0 +0100
+++ v4l-dvb-17554cc18063_1/dvb-spec/dvbapi/intro.tex2009-02-26
20:04:57.245819770 +0100
@@ -7,49 +7,84 @@
The reader of this document is required to have some knowledge in the
area of digital video broadcasting (DVB) and should be familiar with
part I of the MPEG2 specification ISO/IEC 13818 (aka ITU-T H.222),
-i.e you should know what a program/transport stream (PS/TS) is and what is
-meant by a packetized elementary stream (PES) or an I-frame.
-
-Various DVB standards documents are available from
-\texttt{http://www.dvb.org/} and/or \texttt{http://www.etsi.org/}.
+i.e you should know what a program stream or transport stream (PS/TS) is
+and what is meant by a packetized elementary stream (PES) or an I-frame.
+Various DVB standards documents are available from
\texttt{http://www.dvb.org/}
+and/or \texttt{http://www.etsi.org/}.
It is also necessary to know how to access unix/linux devices and how
to use ioctl calls. This also includes the knowledge of C or C++.
+The goal of this API is to provide a consistent abstraction layer for
+different digital TV hardware, allowing software applications to be
+developed without hardware details as well as serving as driver
+developers reference.
+
+\newpage
\section{History}
-The first API for DVB cards we used at Convergence in late 1999
-was an extension of the Video4Linux API which was primarily
-developed for frame grabber cards.
-As such it was not really well suited to be used for DVB cards and
+The first API for DVB devices was used at Convergence in late 1999
+as an extension of the Video4Linux API which was p
Re: V4L2 spec
Mauro Carvalho Chehab schrieb: On Mon, 09 Mar 2009 19:46:34 -0400 Andy Walls wrote: and integrating it into the existing v4l docbook, I'm not sure of the value in that. The DVB conversion to docbook allows us to add it at the kernel docbook docs (probably, not the entire doc, but the parts that describe the internal kernel API). Implmenting something to multiple (or multi-volume) specifications is indeed a pain, but it makes documentation maintenance easier as the task is easily divided along areas of personnel expertise. Assuming the rate of documentation maintencance does not rapidly increase, keeping documentation maintenace simple is paramount. If you take a look on V4L docbooks, it is divided into multiple volume files: biblio.sgml pixfmt-nv16.sgml vidioc-enumstd.sgml common.sgml pixfmt-packed-rgb.sgml vidioc-g-audioout.sgml compat.sgml pixfmt-packed-yuv.sgml vidioc-g-audio.sgml controls.sgmlpixfmt-sbggr16.sgml vidioc-g-crop.sgml dev-capture.sgml pixfmt-sbggr8.sgml vidioc-g-ctrl.sgml dev-codec.sgml pixfmt-sgbrg8.sgml vidioc-g-enc-index.sgml ... If we merge DVB there, for sure we should break it into some files, and maybe even having they on separate directories. Also multiple specifcations (or volumes) clearly group requirements into large chunks of "I don't care about that volume" and "I do care about this volume". Combining the V4L2 and DVB spec into one volume would probably be a strategic error for some tactical advantage in dealing with hybrid devices. This is a good point. On my opinion, it seems good to merge the docs. This is just my 2 cents. If we merge both, IMO, we should break the doc into two parts, being one for analog and another for digital, with an introductory text with the hybrid devices glue. If we decide not to merge, we can at least try to follow the same model on both documents, and link a common sgml introductory text for hybrid devices to be added on both documents. Cheers, Mauro What about a two step aproach for each chapter? - doing work on *contents* with developers inside linuxtv dvb wiki on standard wiki page - convert wiki text to docbook (textformatting stuff) by someone else. By doing so, the work load would be split into two independend topics, work on contents in wiki and afterwards textformatting of that agreed contents without help of developers afterwards and supplying to ML as patch. If we would do so, one would prepare a wiki page with the actual contents of one chapter of the current api and set a deadline for editing that page. Developers should edit contents (easy and fast on wiki) until deadline. It would improve greatly the speed of that work. Keeping the logical structure of the document would also allow to have the "I don't care about that volume" feature as well to merge the decoder of the FF cards into V4l2 mpeg decoder section. Introduction What you need to know (remove) History (as short as possible) Overview Linux DVB Devices API include files DVB Frontend API (add a lot of missing stuff here.) Frontend Data Types Frontend Function Calls DVB Demux Device Demux Data Types Demux Function Calls DVB Video Device (merge with v4l2 mpeg decoders) DVB Audio Device (merge with v4l2 mpeg decoders) DVB CA Device CA Data Types DVB Network API DVB Net Data Types Kernel Demux API Kernel Demux Data Types Demux Directory API Demux API Demux Callback API TS Feed API Section Feed API Examples --Winfried -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: V4L2 spec
Devin Heitmueller schrieb: On Mon, Mar 9, 2009 at 6:03 PM, wk wrote: Its a bad idea to expect someone else, the magic volunteer, doing work with *deep impact* on the dvb driver API structure or documentation. Working on this topic determines complete usability of the driver, so MAIN DEVELOPERS have to REVIEW and CONTRIBUTE. If they think, that they cannot do such work in parallel, they should to stop work on drivers for some time. Cut me a $25,000 check and I'll happily do it. Otherwise, don't tell a bunch of volunteer developers how they should be spending their time. What you happen to think is the important is not necessarily what developers feel is the most valuable use of their time. Devin, during your work on drivers you use a lot of tools and applications, most probably a lot of them beeing open-source. Did YOU spend 25000usd for each of the developers of that tools which documentation you was using? Hopefully - after such a comment. Documentation is part of development. -Winfried -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: V4L2 spec
I think so. The better would be to convert DVB api to docbook (as used by all other kernel documents), and add a developers document for the kernel API for both at the kernel documentation structure). However, this is a huge task that someone should volunteer for doing, otherwise, it won't happen. Cheers, Mauro Sorry Mauro, but i disagree with you. Its a bad idea to expect someone else, the magic volunteer, doing work with *deep impact* on the dvb driver API structure or documentation. Working on this topic determines complete usability of the driver, so MAIN DEVELOPERS have to REVIEW and CONTRIBUTE. If they think, that they cannot do such work in parallel, they should to stop work on drivers for some time. Status from application side of view at the moment: *not usable* without re-inventing the wheel. The very same with the structures in frontend.h, a lot of things are not understandable. I give you some examples (i could give more...): - TRANSMISSION_MODE_4K is missing, but still mentioned in 300468 v.1.9.1 "6.2.13.4 Terrestrial delivery system descriptor" - the same for BANDWIDTH_5_MHZ, also 300468 v.1.9.1 "6.2.13.4 Terrestrial delivery system descriptor" - POLARIZATION for QPSK frontends is nowhere defined in frontend.h at all, forcing applications to do its own definitions, "6.2.13.2 Satellite delivery system descriptor" gives clear definitions - so why are they not defined in frontend.h? - ATSC frontends are mixed cable and terrestrian, whereas older DVB-C and DVB-T are *strictly* separated - struct dvb_qpsk_parameters is missing (at least!) to be usable again * fe_modulation_t * fe_pilot_t * fe_rolloff_t * fe_delivery_system_t * west_east_flag * scrambling_sequence_selector * multiple_input_stream_flag - nearly the same for dvb_qam_parameters, dvb_ofdm_parameters, dvb_atsc_parameters..., at least delivery_system needs to be here Working on documentation would fix *all* of this problems. Regards, Winfried -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: V4L2 spec
Hans Verkuil wrote: Hi Mauro, I noticed that there is an ancient V4L2 spec in our tree in the v4l/API directory. Is that spec used in any way? I don't think so, so I suggest that it is removed. The V4L1 spec that is there should probably be moved to the v4l2-spec directory as that is where people would look for it. We can just keep it there for reference. The documentation on www.linuxtv.org is also out of date. How are we going to update that? I think that a good schedule would be right after a kernel merge window closes. The spec at that moment is the spec for that new kernel and that's a good moment to update the website. The current spec is really old, though, and should be updated asap. Note that the specs from the daily build are always available from www.xs4all.nl/~hverkuil/spec. I've modified the build to upload the dvbapi.pdf as well. Regards, Hans Wouldn't it make sense to merge both apis, v4l2 and dvb together? - dvb api is completely outdated, would be good to be rewritten anyway. - v4l2 and dvb share the same hg - v4l2 and dvb share the same wiki - a lot of developers are active in both topics - any person interested in video and tv could be directed to the same file Just some thoughts to the topic.. --Winfried -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dvb-api: update documentation, chapter1
Why do I have a feeling even the updated doc will be full of spelling & grammatical errors? ;) Probably, because none of the writers so far where native English. Therefore i'am really happy that *you* now took over all the responsibility to find all that spelling and grammatical errors. ;-) Also, you might want to consider changing "DVB cards" to "DVB devices". For example, I don't know anybody who refers to USB DVB devices as 'DVB cards'. Yes, makes sense. But at the writing time of that API- more then 6 years ago - most probably nobody was thinking of USB for a DVB device. --Winfried -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dvb-api: update documentation, chapter1
Mauro Carvalho Chehab wrote:
+
+For this API documentation applies an even/odd versioning scheme, stating
+unstable or stable versions of that API. Only stable API versions should
+be used for developing drivers and applications.
Hmm... I wouldn't add the above. I don't think we should use such versioning
scheme for docs.
I removed that lines.
Can you please comment, how the dvb-developers want to deal with in
future with the transition to a updated documentation?
By looking at the differences between headers and doc, it will take at
least one year or even longer to finish.
Only a comment "currently under review" is probably not sufficient here.
Would it help to add a extra page "Revision History" like its done on
v4l api? If so, please suggest a format for the page.
+In 2003 Convergence and Toshiba Electronics Europe GmbH started the
development
+of
+\href
{http://www.linuxtv.org/downloads/linux-dvb-api-v4/linux-dvb-api-v4-0-3.pdf}{DVB
API Version 4}
+with public discussion on the linux-dvb mailing list. The goal was a
complete
+new API, reflecting that PCs and embedded platforms are diverging. On a PC
+usually a budget card provides the full raw transport stream and decoding
+and processing is main CPU's task. On embedded platforms, however, data is
+multiplexed by specialized hardware or firmware for direct application use
+which relieves the main CPU from these tasks. Therefore, Linux DVB
+API Version 4 was suggested, but unfortunally never completed.
It seems better to say, instead, that "Version 4 was suggested, but it weren't
completed nor implemented".
I put in here as suggested by Derek:
"Version 4 was suggested but neither completed, nor implemented"
+Today, the LinuxTV project is an independend and non-profit community
project
s/independend/independent/
Changed.
+by DVB/V4L enthusiasts and developers interested in Digital TV and
Analog TV,
+sharing the same hg tree.
+
+However, this document describes only the digital TV part.
I would replace the last paragraph by:
"This document describes the digital TV API. For Analog TV and radio, please consult
V4L2 API."
IMO, we should also add such cross-reference at the V4L2 API, and point both to
linuxtv.org website (so, adding the corresponding \href pointers), for those
interested on getting the other API to know here both are available.
Changed and linked to
http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/v4l2spec/v4l2.pdf
+
+
+With the further development of newer DTV standards, the existing version
+3 of the Linux DVB API was no longer able to support all DTV standards and
+newer hardware. Two concurrent approaches to overcome the problem where
+proposed, \texttt{Multiproto} and \texttt{S2API}.
+
+At
+\href {http://www.linuxtv.org/news.php?entry=2008-09-19.mchehab}{Linux
Plumbers Conference 2008}
+the decision was made towards to S2API, basically an extension to
+\texttt{DVB API Version 3} called \texttt{DVB API Version 5}.
+
+
+This Linux DVB API documentation will be extended to reflect these
additions.
While we don't finish adding the S2API parts, maybe we should say instead:
This document is currently under review to reflect the S2API additions.
Changed, but please answer the question above.
Also changed: "dvb card" -> "dvb device" as suggested by Derek.
updated patch below.
-- Winfried
diff -Nurp v4l-dvb-17554cc18063/dvb-spec/dvbapi/dvbapi.tex
v4l-dvb-17554cc18063_1/dvb-spec/dvbapi/dvbapi.tex
--- v4l-dvb-17554cc18063/dvb-spec/dvbapi/dvbapi.tex2009-02-23
16:26:38.0 +0100
+++ v4l-dvb-17554cc18063_1/dvb-spec/dvbapi/dvbapi.tex2009-02-26
18:40:35.008186330 +0100
@@ -1,4 +1,4 @@
-\documentclass[a4paper,10pt]{book}
+\documentclass[a4paper,10pt,oneside]{book}
\usepackage[dvips,colorlinks=true]{hyperref}
\usepackage{times}
diff -Nurp v4l-dvb-17554cc18063/dvb-spec/dvbapi/intro.tex
v4l-dvb-17554cc18063_1/dvb-spec/dvbapi/intro.tex
--- v4l-dvb-17554cc18063/dvb-spec/dvbapi/intro.tex2009-02-23
16:26:38.0 +0100
+++ v4l-dvb-17554cc18063_1/dvb-spec/dvbapi/intro.tex2009-02-26
20:04:57.245819770 +0100
@@ -7,49 +7,84 @@
The reader of this document is required to have some knowledge in the
area of digital video broadcasting (DVB) and should be familiar with
part I of the MPEG2 specification ISO/IEC 13818 (aka ITU-T H.222),
-i.e you should know what a program/transport stream (PS/TS) is and what is
-meant by a packetized elementary stream (PES) or an I-frame.
-
-Various DVB standards documents are available from
-\texttt{http://www.dvb.org/} and/or \texttt{http://www.etsi.org/}.
+i.e you should know what a program stream or transport stream (PS/TS) is
+and what is meant by a packetized elementary stream (PES) or an I-frame.
+Various DVB standards documents are available from
\text
Re: POLL: for/against dropping support for kernels < 2.6.22
Should we drop support for kernels <2.6.22 in our v4l-dvb repository? _: Yes _: No YES. Optional question: Why: I assume that the main goal should be development of linux v4l/dvb drivers to be included in *new* kernel versions. These dont need compat code. But beside of the main goal there are requirements and other goals - simplify development and save time (skip) - keep code as easy as possible (skip) - having as many testers as needed (don't skip or choose kernel version suitable) - support of linux users who aren't able to update (either dont skip or provide backports in regular intervals. still easier to implement) looking at this it will hurt only users from embedded hardwrae, but at least a bunch of them cannot compile modules anyway. Might be solved by (i.e. yearly) backports. Would be also interesting which kernel versions are used by list members. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dvb-api: update documentation, chapter1
Since dvb-api doc is still outdated by six years...
The following patch changes dvbapi.pdf as following:
___
- change from twosided book format to singlesided book format.
* By doing so, the readability is improved and on the right-hand side
is more space on every second page.
- change copyright notice on first page by adding "2008, 2009
www.linuxtv.org"
- add "The Linux DVB Developers http://www.linuxtv.org"; to 'written by'
- increase API Version number to 5
- change Version Number and date
-- 24/07/2003V 1.0.0
++ 22/02/2009Version 1.1.0 <- unstable version now, every time api
is changed version should be increased now
- chapter 1 - What you need to know
* added goal: "consistent abstraction layer for
different digital TV hardware, allowing software applications to be
developed without hardware details as well as serving as driver
developers reference"
* added comment: odd api version numbers = unstable -> not to be used
for driver/app development
- chapter 1 - history
* add History of DVB API v 4
* add comment LinuxTV project beeing an independend and non-profit
community
* add reasons for DVB API v 5 and decision on Plumbers Conference 2008
towards S2API
- chapter 1 - Overview
* changed "DVB PCI card" wherever found, since API doesnt depend on
PCI bus
* changed "MPEG picture and sound decoding" to "MPEG video and audio
decoding",
since mpeg picture is misleading
- fix some typos inside chapter 1
- fix "Overfull \hbox" warnings from chapter 1 (*only* chapter 1 for now..)
Signed-off-by: Winfried Koehler
___
Please response, comment, improve, review, apply. Do not ignore silently,
having a new API doc should be hard requirement for next kernel versions.
Regards, Winfried
diff -Nrup v4l-dvb-359d95e1d541/dvb-spec/dvbapi/dvbapi.tex
v4l-dvb-a7ea3df69673/dvb-spec/dvbapi/dvbapi.tex
--- v4l-dvb-359d95e1d541/dvb-spec/dvbapi/dvbapi.tex2009-02-22
17:07:48.123742503 +0100
+++ v4l-dvb-a7ea3df69673/dvb-spec/dvbapi/dvbapi.tex2009-02-21
17:33:29.557033066 +0100
@@ -1,4 +1,4 @@
-\documentclass[a4paper,10pt]{book}
+\documentclass[a4paper,10pt,oneside]{book}
\usepackage[dvips,colorlinks=true]{hyperref}
\usepackage{times}
diff -Nrup v4l-dvb-359d95e1d541/dvb-spec/dvbapi/intro.tex
v4l-dvb-a7ea3df69673/dvb-spec/dvbapi/intro.tex
--- v4l-dvb-359d95e1d541/dvb-spec/dvbapi/intro.tex2009-02-18
13:49:37.0 +0100
+++ v4l-dvb-a7ea3df69673/dvb-spec/dvbapi/intro.tex2009-02-22
16:03:12.610230293 +0100
@@ -7,36 +7,73 @@
The reader of this document is required to have some knowledge in the
area of digital video broadcasting (DVB) and should be familiar with
part I of the MPEG2 specification ISO/IEC 13818 (aka ITU-T H.222),
-i.e you should know what a program/transport stream (PS/TS) is and what is
-meant by a packetized elementary stream (PES) or an I-frame.
-
-Various DVB standards documents are available from
-\texttt{http://www.dvb.org/} and/or \texttt{http://www.etsi.org/}.
+i.e you should know what a program stream or transport stream (PS/TS) is
+and what is meant by a packetized elementary stream (PES) or an I-frame.
+Various DVB standards documents are available from
\texttt{http://www.dvb.org/}
+and/or \texttt{http://www.etsi.org/}.
It is also necessary to know how to access unix/linux devices and how
to use ioctl calls. This also includes the knowledge of C or C++.
+The goal of this API is to provide a consistent abstraction layer for
+different digital TV hardware, allowing software applications to be
+developed without hardware details as well as serving as driver
+developers reference.
+
+For this API documentation applies an even/odd versioning scheme, stating
+unstable or stable versions of that API. Only stable API versions should
+be used for developing drivers and applications.
+\newpage
\section{History}
-The first API for DVB cards we used at Convergence in late 1999
-was an extension of the Video4Linux API which was primarily
+The first API for DVB cards was used at Convergence in late 1999
+as an extension of the Video4Linux API which was primarily
developed for frame grabber cards.
+
+
As such it was not really well suited to be used for DVB cards and
their new features like recording MPEG streams and filtering several
section and PES data streams at the same time.
-In early 2000, we were approached by Nokia with a proposal for a new
+
+In early 2000, Convergence was approached by Nokia with a proposal for
a new
standard Linux DVB API.
As a commitment to the development of terminals based on open standards,
Nokia and Convergence made it available to all Linux developers and
published it on \texttt{http://www.linuxtv.org/} in September 2000.
-Convergence is the maintainer of the Linux DVB API.
-Together with the LinuxTV community (i.e. you, the reader of this
do
Re: RFCv1: v4l-dvb development models & old kernel support
Hans Verkuil wrote: Comments? Hans As only beeing reader of this list.., why not simply reduce the work load by - reducing the number of supported kernel versions to five major versions? Currently 2.6.28 would mean down to 2.6.23, this would be enough cover all nearly up-to-date distributions. Users from embedded devices are anyway mostly not able to compile or use newer drivers. - not changing to git, already since this generates a lot of work Not too far away dev was changed from cvs to hg, and already there some pieces are left over (for example that api stuff). - force users to upgrade their kernel if (breaking these backward compat, and only if) *major* upgrades inside standard kernel would require a very huge amount of backporting, for example that i2c stuff. I guess such solution would help immediately. --Winfried -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
linux/include/dvb/frontend.h : missing capability flags
Some time ago two new members were added in frontend.h to enum fe_code_rate: - FEC_3_5 - FEC_9_10 But the matching capability flags for that are still missing, signalling applications support for those: - FE_CAN_FEC_3_5 - FE_CAN_FEC_9_10 It would be possible to use 0x100, 0x200 for that to get some consistent and logically understandable file, but there would be also the second possibility to remove FE_CAN_FEC_1_2 FE_CAN_FEC_2_3 FE_CAN_FEC_3_4 FE_CAN_FEC_4_5 FE_CAN_FEC_5_6 FE_CAN_FEC_6_7 FE_CAN_FEC_7_8 FE_CAN_FEC_8_9 This would assume, that all related drivers supports all of these (what they should do anyway..). This would also make sense, since all other frontend related properties except modulation are also not explicitly stated (for example there's also no "FE_CAN_BANDWIDTH_6_MHZ or FE_CAN_GUARD_INTERVAL_1_8") Opinions? Secondly, inside frontend.h "DTV_API_VERSION" is defined twice, line 302 and 303: #define DTV_API_VERSION35 #define DTV_API_VERSION35 Regards, Winfried -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DVB v3 API question
Mauro Carvalho Chehab wrote: On Mon, 16 Feb 2009 23:50:50 +0100 Hans Verkuil wrote: Hi all, I've made a v4l-dvb tree containing the old DVB API sources as found here: http://www.linuxtv.org/cgi-bin/viewcvs.cgi/DVB/doc/dvbapi/. This tree is here: http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-api It seems that we did suplicate work, except that, on your tree, you just dropped all CVS history. Anyway, the DVB API were just added to the repository with all the CVS history. Run 'make spec' to build both the v4l2-spec and the dvb-spec, or run 'make -C dvb-spec' to build only the latter. You'll need the transfig package to get the dvb-spec to compile. I didn't touch at the Makefiles. Feel free to submit this as a patch for the current tip. My question is if this is indeed the most recent version that we have? There is a dvb-api-v4 pdf document, but it is my understanding that v4 was actually never implemented and never got beyond the proposal stage. Is that correct? Or are there bits and pieces that were actually used? The original documentation for v4 is here: http://www.linuxtv.org/cgi-bin/viewcvs.cgi/dvb-kernel-v4/linux/Documentation/dvb/ V4 is a proposal that were never finished. We're currently using V3 + S2API. This is named as V5. We need, of course, to update the docs to rename it to Version 5 and add S2API specs there. We should also review if the current DVB core and drivers match the V3. I suspect that maybe there are other changes that aren't applied yet at the docs. Thanks Mauro and Hans for your fast help, its a good starting point for updates. The compiling requirements are not complete, missing are - TransFig/fig2dev from xfig homepage - dvipdf (where to find that btw..?) The last one, dvipdf can be replaced by "dvipdfm", which is part of teTex-3.0 which is anyway needed by only changing one line in Makefile: dvbapi.pdf: dvbapi.dvi -dvipdf $< $@ +dvipdfm -o $@ $< Regards, Winfried -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DVB-API v5 questions and no dvb developer answering ?
Devin Heitmueller wrote: As always we continue to welcome patches, including for the documentation. Instead of bitching and moaning, how about you roll up your sleeves and actually help out? Let's try to remember that pretty much all the developers here are volunteers, so berating them for not doing things fast enough for your personal taste is not really very productive. Regards, Devin Devin, can you please explain, how others should contribute to an dvb api if - the only DVB API file to be found is a pdf file, and therefore not editable. Which files exactly to be edited you are writing of? - one doesn't know which ioctls exist for what function, which return codes and arguments, how to understand and to use..? What you suggest is almost impossible to someone not perfectly familiar with the drivers, only for dvb experts who have written at least a bunch of drivers. Its something different than sending patches for one single driver where some bug/improvement was found. On the other hand, in principle a driver without existing api doc is useless. Nobody can use it, the same for drivers with undocumented new features. Regards, Winfried -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
DVB-API v5 questions and no dvb developer answering ?
The last week two guys were kindly asking here on the list where to find a written DVB-API v5 documentation, but nobody of the dvb driver community was answering. http://www.mail-archive.com/linux-media@vger.kernel.org/msg01350.html http://www.mail-archive.com/linux-media@vger.kernel.org/msg01300.html Does that mean that: - dvb developers are currently not interested in application developers integrating new DVB-API v5? or.. - no dvb developer reading that list knows something about documentation? or.. - does it simply not exist, so who is working on that api documentation stuff? The offical documentation found on linuxtv.org is outdated and already 5 years old, and describes only api v3. See http://www.linuxtv.org/downloads/linux-dvb-api-1.0.0.pdf Please read also the announcements on linuxtv: http://www.linuxtv.org/news.php?entry=2008-09-23.mchehab [quote] Some improvements were proposed by the LinuxTV developers, in order to improve the S2API, including: ... * Update DVB API documentation to reflect the API changes;" [/quote] But also this statement is already now five months old, so i guess documentation should be finished meanwhile or at least started and usable/redistributable.. Is it possible to get some information on that topic? -Winfried -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bad sound on HVR1300 & cx88-alsa not loading anymore for HVR1300
Hello, I'm running Ubuntu 8.10, and 2.6.27-11-generic kernel. I also tried compiling the newest modules from linuxtv. The first problem: The sound from my HVR1300 is really bad, it like a robotic sound, with high tones in it! 2nd problem: cx88-alsa module is not loading automaticly when booting my system. While my HVR1300 needs it ! Regards, Jean-Louis Dupond So that means you do have at least any sound, different as it is for me? I guess you're not using the cx88_blackbird module, since you use the alsa device for sound? Are you using PAL video norm on TV input and does your initialisation differ from mine, see some posts before yours? -Winfried -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Please help. HVR1300 - no sound on tv input -> wrong tuner initialization?
I'm trying to use the cx88_blackbird mpeg encoder on a hvr-1300.
I'm able to get a picture if i'm tuning to a tv frequency, but no sound
(but audio noise, so the mpeg encoder itself works).
Please note: that card supports DVB-T, PAL-{b/g,d/k,-50,-60} and CCIR
L/L' and FM radio,
see datasheet from other card using the same tuner:
http://www.creatix.de/support/download/gruppe6/CTX917_spec.pdf
After loading the drivers, i'm initializing the card using v4l2-ctl and
try to capture using cat:
# setting pal video size
v4l2-ctl -d /dev/video2 -v width=720,height=576
# setting mpeg encoder to pal video norm
v4l2-ctl -d /dev/video2 -s pal-b
# setting v4l2 device to pal-b(g)
v4l2-ctl -d /dev/video1 -s pal-b
# setting video input to 0 (television)
v4l2-ctl -d /dev/video1 -i 0
# tuning v4l2 dev to known working freq: 245.25MHz
v4l2-ctl -d /dev/video1 -f 245.25
# enshure that audio is not muted
v4l2-ctl -d /dev/video1 -c mute=0
# setting audio volume to maximum (63)
v4l2-ctl -d /dev/video1 -c volume=63 >> ~/status.txt
# card should be initialized now, so start capturing using MPEG2-PS format
cat /dev/video2 > ~/test.ps
I can watch the recorded video in vlc, video is okay - but sound is only
white noise (like mistuned radio or tv)..
I also notice, if i'm moving freq by ~1MHz video nearly disappear, but
then i can hear at least a little bit audio (but still noisy then).
I therefore think that the audio comes from the tuner and only the tuner
is misconfigured.
What i found out so far..
Loading of the card seems to be successful:
cx88/0: cx2388x v4l2 driver version 0.0.6 loaded
cx8800 :00:0c.0: PCI INT A -> Link[LNKD] -> GSI 5 (level, low) -> IRQ 5
cx88[0]: subsystem: 0070:9601, board: Hauppauge WinTV-HVR1300
DVB-T/Hybrid MPEG Encoder [card=56,autodetected], frontend(s): 1
cx88[0]: TV tuner type 63, Radio tuner type -1
wm8775' 1-001b: chip found @ 0x36 (cx88[0])
tuner' 1-0043: chip found @ 0x86 (cx88[0])
tda9887 1-0043: creating new instance
tda9887 1-0043: tda988[5/6/7] found
tuner' 1-0061: chip found @ 0xc2 (cx88[0])
tuner' 1-0063: chip found @ 0xc6 (cx88[0])
cx88[0]: i2c init: enabling analog demod on HVR1300/3000/4000 tuner
tveeprom 1-0050: Hauppauge model 96019, rev C2A0, serial# 307652
tveeprom 1-0050: MAC address is 00-0D-FE-04-B1-C4
tveeprom 1-0050: tuner model is Philips FMD1216ME (idx 100, type 63)
tveeprom 1-0050: TV standards PAL(B/G) PAL(I) SECAM(L/L') PAL(D/D1/K)
ATSC/DVB Digital (eeprom 0xf4)
tveeprom 1-0050: audio processor is CX882 (idx 33)
tveeprom 1-0050: decoder processor is CX882 (idx 25)
tveeprom 1-0050: has radio, has IR receiver, has IR transmitter
cx88[0]: hauppauge eeprom: model=96019
tuner-simple 1-0061: creating new instance
tuner-simple 1-0061: type set to 63 (Philips FMD1216ME MK3 Hybrid Tuner)
cx88[0]/0: found at :00:0c.0, rev: 5, irq: 5, latency: 32, mmio:
0xe500
cx88[0]/0: registered device video1 [v4l2]
cx88[0]/0: registered device vbi1
cx88[0]/0: registered device radio0
cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.6 loaded
cx88[0]/2: cx2388x 8802 Driver Manager
cx88-mpeg driver manager :00:0c.2: PCI INT A -> Link[LNKD] -> GSI 5
(level, low) -> IRQ 5
cx88[0]/2: found at :00:0c.2, rev: 5, irq: 5, latency: 32, mmio:
0xe300
cx2388x blackbird driver version 0.0.6 loaded
cx88/2: registering cx8802 driver, type: blackbird access: shared
cx88[0]/2: subsystem: 0070:9601, board: Hauppauge WinTV-HVR1300
DVB-T/Hybrid MPEG Encoder [card=56]
cx88[0]/2: cx23416 based mpeg encoder (blackbird reference design)
cx88[0]/2-bb: Firmware and/or mailbox pointer not initialized or corrupted
cx88-mpeg driver manager :00:0c.2: firmware: requesting
v4l-cx2341x-enc.fw
cx88/2: cx2388x dvb driver version 0.0.6 loaded
cx88/2: registering cx8802 driver, type: dvb access: shared
cx88[0]/2: subsystem: 0070:9601, board: Hauppauge WinTV-HVR1300
DVB-T/Hybrid MPEG Encoder [card=56]
cx88[0]/2: cx2388x based DVB/ATSC card
cx8802_alloc_frontends() allocating 1 frontend(s)
tuner-simple 1-0061: attaching existing instance
tuner-simple 1-0061: type set to 63 (Philips FMD1216ME MK3 Hybrid Tuner)
DVB: registering new adapter (cx88[0])
DVB: registering adapter 1 frontend 0 (Conexant CX22702 DVB-T)...
cx88[0]/2-bb: Firmware upload successful.
cx88[0]/2-bb: Firmware version is 0x02060039
cx88[0]/2: registered device video2 [mpeg]
if i switch on debugging for the driver loaded i can see additional:
cx88[0]: TV tuner type 63, Radio tuner type -1<<
thats wrong here, Philips FMD1216ME has FM radio support.
...
tuner' 1-0043: type set to tda9887
tuner' 1-0043: tv freq set to 0.00
<< should be set to something *valid* here, not zero.
tuner' 1-0043: TV freq (0.00) out of range (44-958)
tda9887 1-0043: Unsupported tvnorm entry - audio muted << wrong tv
norm, may be the reason for no audio?
...
cx88[0]/0: registered device vi
