From owner-freebsd-multimedia Sat Jun 28 09:47:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA26315 for multimedia-outgoing; Sat, 28 Jun 1997 09:47:11 -0700 (PDT) Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id JAA26307 for ; Sat, 28 Jun 1997 09:47:08 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Sat, 28 Jun 1997 12:46:26 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA26427; Sat, 28 Jun 97 12:46:24 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id MAA25643; Sat, 28 Jun 1997 12:44:44 -0400 Message-Id: <19970628124444.04368@ct.picker.com> Date: Sat, 28 Jun 1997 12:44:44 -0400 From: Randall Hopper To: Guido van Rooij Cc: Steve Passe , multimedia@freebsd.org Subject: European Channel Tuning (was Re: fxtv patches) References: <19970628104127.24586@ct.picker.com> <199706281526.RAA01312@gvr.win.tue.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <199706281526.RAA01312@gvr.win.tue.nl>; from Guido van Rooij on Sat, Jun 28, 1997 at 05:26:09PM +0200 Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk (I'm CCing Steve since he might have some info to add, in particular where the best place to put the channel-to-string mappings for Europe is. Guido van Rooij: |Ah ok. Btw I have been thinking about solving the `plus channels' |problem, and I think what I want to do is this: |In stead of having a numeric channel field, have a string field. |In you resources you can specify which channels you have and either |their channel no. or their frequency. If you do not set a channel |name you'll just get your old number back. What do you think? | |The reason that I want something like that is that in Europe we |do not have channel numbers as identifiers but channel names. |Hmm..now that I think of it: I would rather see a nnew file, lets say |.fxtv-channels, in stead of resources. Anyway, I'd like to know |what you plan to do with fxtv and if my views fit in there ;-) Well, from what you said, it sure sounds like there's a need for frequency-to-string mappings as opposed to frequency-to-channelnum mappings. Glancing down in brooktree848.c and searching down for "Western European", I assume something like the names on the rightmost column of the commented-out table are what you're talking about. Let me ask a few more questions to get a handle on the specifics so we can determine the best place for this table. If I understood, there are no "channel numbers" in Europe, just channel names. So I assume the channel numbers in the driver are pretty well arbitrary. Also, can we assume that the channel names in a frequency-to-name mapping table are constant for a particular broadcast standard? (e.g. a specific frequency is always identified as "N21" or "E1"). If so, it seems like we should either: 1) keep the arbitrary channel numbers in the driver for the existing interface, and add a new driver interface so it can tell apps what the ad-hoc channel number -to- name mappings are (e.g. #1 == "N21", #2 == "E2"), OR 2) Modify the driver interface to accept a channel string specifier instead of (or in addition to) the existing channel number specification interface (for US, string would just be chan number in string form), OR 3) Instead, have apps manage the name-to-frequency mappings, and have them talk to the driver in frequencies (for all freq stds, or maybe just for channel-numberless standards). Both #1 & #2 hide the app from the mappings from frequencies to channel numbers/names, which is good if its practical. This is a big plus because each new app won't have to know how to convert N21 to a frequency. We may need to resort to #3 if there is enough variability in or space required for the freq-to-name table such that its impractical to encode this knowledge in the driver. If so, we should come up with a common FreeBSD link library so each new bt848 TV app doesn't need to duplicate the name-to-frequency mappings, but rather can just link with the library and talk channel names and channel numbers instead of frequencies, as with options #1 & #2. |ps: so you know what this is: |bktr0: ioctl: tsleep error 35 100001c |I keep getting them everytime when I freeze the window. Yeah, you'll get this when a single-frame capture (aka CAP_SINGLE, or freeze frame) fails. This occurs when the driver timed-out waiting on 1 or 2 fields to complete capture, and so it couldn't assemble the frame. Where I've seen it happen is when the tuner isn't in complete sync with the video (on weak channels the tuner can sometimes drift off frequency a little). Looking in my console window, I see that there's one there from earlier this morning. Randall