Date: Mon, 28 Jun 1999 18:19:00 -0400 From: Randall Hopper <aa8vb@ipass.net> To: Roger Hardiman <roger@cs.strath.ac.uk> Cc: Frode Vatvedt Fjeld <frodef@acm.org>, Juha.Nurmela@quicknet.inet.fi, freebsd-multimedia@FreeBSD.ORG Subject: Re: bt848 channel frequencies Message-ID: <19990628181900.A3087@ipass.net> In-Reply-To: <37777968.759F59E9@cs.strath.ac.uk>; from Roger Hardiman on Mon, Jun 28, 1999 at 02:32:24PM %2B0100 References: <2hzp2tfr3t.fsf@dslab7.cs.uit.no> <374AA5BB.7C87D8C2@cs.strath.ac.uk> <2hogj9f0p6.fsf@dslab7.cs.uit.no> <2hpv2kba67.fsf@dslab7.cs.uit.no> <37777968.759F59E9@cs.strath.ac.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Roger Hardiman: |I'm just back from vacation with 1850 emails to get through. Ouch. Been there before :-) Thank goodness for procmail. Welcome back. |/usr/local/share/tuner-freq-sets.rc: |[UK] # Country name+format eg UK, USA Cable, USA Wireless |E37 12450 # channel 'name' to frequency mapping. |E38 12500 # these are just made up |E39 12550 |E40 12600 ... |/etc/tuner.rc: |[Glasgow] # Location name |UK # Country name (from the /usr/local/share file) |BBC 1 E30 +0.001 |BBC 2 E37 +0.500 |CH 5 E38 0.0 |MY VCR E36 -0.333 |*** Note the Fine Tuning offsets need to be stored too. We need a channel set tie-in between these files (a countryname+format tie-in, in the above terminology), if for no other reason than folks often have access to two or more channel sets at once. For example: antenna, cable, and satellite at one location. For example, NBC may be channel 9 on antenna (NABCST) while it is channel 7 on cable (CABLEIRC). |This second file in /etc should be writable by FXTV |either directly or via the library. You might not have intended what this implied. Fxtv code shouldn't be writing or reading this file directly IMO. Maybe libtv, but not fxtv. The idea with these files is to make them generally available to all TV driver clients, so there should be one block of code somewhere reading and writing this. That's probably what you meant. I'd just rephrase to say the file should be writable by users wanting to configure their stations (a job to be performed by a heretofore undesignated GUI -- maybe a separate GUI program -- utilizing libtv to access the configuration information). |This also means that the file should not be in /etc |but in the users home directory. Makes sense. Maybe a system default could be installed in /etc/tuner.rc once it's been cooked by a priviledged user. So maybe libtv would always write the updates to a cfg file in $HOME, but when reading, it would pull in /etc/tuner.rc if it doesn't find a $HOME version. Just a thought. |In FXTV, I should be able to |a) select the country |b) run through the list of channels, E35, E36, E37 etc |c) find a channel, fine tune it and save it, I think it's premature to say this would be fxtv. "Some GUI and/or command-line utility" would provide this functionality. I'd like to have a separate program that does this, and just have there be a hook inside fxtv to launch it. This supports one thing we've been trying to accomplish here (besides getting frequency maps out of the driver). That is, to greatly reduce the amount of effort needed to write generic, useful TV apps (GUIs, frame grabbers, webcams, etc.), simplifying where we can and sharing what code we can where it makes sense. libtv is going to be the first big step in that direction. There are other effort-barriers I'm working on busting down. More on that as I have time to develop them. |Then, once the list of actual TV stations is built, |I can select BBC1, or CH 5 or whatever from my Stations list. Yeah, that's the ticket! :-) |Interface to the driver. I originally thought libtuner (or libtv) would |talk directlyto the bt848 driver. The TV or Radio application would then |not need to worry about the tuner ioctls. | |But on second thoughts, perhaps libtuner should just be a |channel->frequency mapping, returning an actual frequency as a uint_64. I definitely agree on the this scope, though I'm not particular about the interface (uint_64 vs struct, etc. -- just something general enough to handle all worldwide TV and radio <whew!>). This also has the advantage that the "channel configuration GUI" doesn't need to depend on the driver interface (ioctl_bt848 & friends), use driver ioctls, and is therefore guarenteed to happily coexist with any app that might be hogging /dev/bktr* or /dev/tuner*. Two users could be running it simultanously -- no sweat. |Then the application (xmradio/fxtv) calls the bt848 driver. Otherwise, |libtuner needs to open the bt848 driver too, and issue ioctls and that |just makes it even more complciated. Right. We need to toss more design discussion around before this happens. I haven't looked at video4linux yet. Presumably this is some of what it addresses. My 2 cents: I'd rather not push just part of the responsibility of bt848 driver communication into a shared library. If/when we go for this, I'd vote for making it all-or-nothing. That is, abstract all of it or don't do it. If the former, apps would make no bt848 ioctls or mess with device file descriptors. Ideally, it would be nice to be able to plug in new TV drivers under the hood with little effort on the app end of things. This might encourage the prospective multimedia driver hackers out there. No need to write your own apps. Use what's there, write driver, and patch in the appropriate stubs to "libtuner" (or whatever it is called). |It cannot hide any OS specific details unless it handles opening the |bt848 device, selecting the audio /mute/mono/stereo/fm sources, volumes |and balances and lanuage selection on TV programs with multiple audio |channels (done by the MSP34xx chips). I was really just thinking about |getting the Frequency mappings out of the bt848 driver. Right. Randall To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990628181900.A3087>