On Fri, 2009-03-27 at 15:36 -0500, Mike Isely wrote: > On Fri, 27 Mar 2009, Martin Dauskardt wrote: > > [...] > > > > > Mike Isely wrote: > > >Remember that opening /dev/radioX still produces the correct result. > > >That is enough for any V4L radio application to use the driver without > > >change. > > > > Yes, opening the radio device works. The driver switches automatically to > > input 3 (radio) and the tuner uses 62,5 Hz steps: > > > > linvdr:~# v4l2-ctl -T -d 0 > > Tuner: > > Capabilities : 62.5 Hz stereo > > Frequency range : 65.0 MHz - 108.0 MHz > > Signal strength : 25% > > Current audio mode : bilingual > > Available subchannels: stereo > > linvdr:~# v4l2-ctl --get-input -d 0 > > Video input : 3 (radio) > > > > But after closing the radio device, these settings still exist. The result > > is, > > that tuning to a TV station does not work. I also checked this with > > v4l2-ctl: > > v4l2-ctl -f 280.25 -d 0 gives no error (but also reports no success). > > > > To be able to tune to a TV frequency I must first set the input to 0: > > > > linvdr:~# v4l2-ctl -T -d 0 > > Tuner: > > Capabilities : 62.5 Hz stereo > > Frequency range : 65.0 MHz - 108.0 MHz > > Signal strength : 25% > > Current audio mode : bilingual > > Available subchannels: mono > > linvdr:~# v4l2-ctl --set-input 0 -d 0 > > Video input set to 0 (television) > > linvdr:~# v4l2-ctl -f 280.25 -d 0 > > Frequency set to 4484 (280.250000 MHz) > > linvdr:~# v4l2-ctl -T -d 0 > > Tuner: > > Capabilities : 62.5 kHz multi-standard stereo lang1 lang2 > > Frequency range : 44.0 MHz - 958.0 MHz > > Signal strength : 99% > > Current audio mode : bilingual > > Available subchannels: stereo > > > > Is this a problem of the application (both v4l2-ctl and pvrinput-plugin), > > or > > should the driver switch to the previous input (as it was before opening > > the > > radio) after closing the radio device ? > > Well that will teach me to reply too quickly. Reading further I think I > understand the issue. This I believe is not a bug. > > When I first read this description, I thought you were saying that the > tuning was messed up after running in radio mode and then switching back > to TV mode. The real issue if I understand this correctly is that it > didn't magically switch back to TV mode when you expected it to. > > Is there a place in the V4L spec that requires the "current input" to be > analog television when /dev/videoX is open? Because if not, then it > really is up to the app to first select the input it wants before > implicitly assuming it can stream from it. If the app fails to select > an input, then why should it expect the driver to magically know what > the input should have been? After all, it will also fail to tune a TV > channel if the previous usage of the driver was to stream from the > s-video input. > > If for example one were to force TV mode every time /dev/video0 were > opened, this could break other apps which happen to on-the-fly open > /dev/video0 multiple times as they run. I believe xawtv (yes I know > it's unmaintained) works this way. > > I could alternatively cause the "previous" input to be selected when > /dev/radioX is closed. I actually had it that way until about a year > ago. However I don't think that's right either, because it's a magical > change that might be confusing if/when other opens take place while > /dev/radioX is open.
According to section 1.5 of the v4l2-spec: "Radio devices have no audio inputs or outputs. They have exactly one tuner which in fact is an audio source, but this API associates tuners with video inputs or outputs only, and radio devices have none of these." So the abstraction is that the radio device is a control and tuning device (like an FM receiver in a home stereo system), but the audio from the tuner is obtained via a soundcard or video device node (like the power amp and speakers in a home stereo system). The /dev/radioX device node has all sorts of "magical" dependencies. In cx18 and ivtv, it's a control only device node that passes no data (no RDS). PCM data comes from /dev/video24 (IIRC). Already at least one app or coordinated set of applications has /dev/radio0 and /dev/video24 open if you're working with the radio. If that app or application set then tries to capture MPEG from /dev/video0, app gets an EBUSY errno. /dev/video0 can still be opened and some ioctl()'s exercised though. So this is where Hans' plan for a "media controller" device may be able to clean things up nicely. Right now, for FM radio, apps are required to know about interdependencies to some degree. The constsituent parts (FM receiver and power amp in my analogy) are presented to userspace as pieces of a working system and apps have to put together their own FM stereo playback system. I believe the intent of the "media controller" device to be presented by drivers was to eliminate this burden of implicit knowledge from applications. Regards, Andy > The definition of the concept of "previous" input > becomes fuzzy then. You might convince me otherwise, but since any app > really should select its desired input before streaming anyway, I think > this is in the end a non-issue. > > -Mike _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
