Robert, > So what happens when a client crashes or the > connection between the client > and the device is lost? ;-) Ok, your semaphore might > expire, but the tuner > may be left in an undefined state... When a new client acquires control of the tuner, the first step is to initialize it, and tune to the new RF channel. As such it doesn't matter what state it was left in. > And how is one client supposed to know what state a > tuner is in anyway, > when the device doesn't know itself...? Or are > clients supposed to send out > broadcast messages before/after reconfiguring a > tuner so that the other > clients know about the change as well? What if a > client is started after a > tuner configuration, is it supposed to send a > broadcast message asking the > other clients what the current tuner configuration > is? Your point about monitoring the other client's control messages is valid. We probably don't want or need to do this. > 1) Design a _proper_ network tuner device which > fully > encapsulates/abstracts the actual hardware, and > handles access control, and > spend the time it takes to develop that. What kind of interface would you like to see? Something like the API provided by the linux-dvb, only available over ethernet instead of an ioctl? > 2) Design a "quick&dirty" network tuner device and > spend just as much time > implementing all kinds of workarounds (aka "hacks") > in your client software > to make it _somewhat_ work, but never quite as > reliable as choice 1) would > allow you. Setting aside the issue of mutual exclusion between multiple clients contending for a given tuner, there is still value and utility in having (multiple) networked tuners with a simple API. Several of the applications that I had in mind (multichannel enhanced-PVR, lookahead channel tuning, multiple-PIP, expanability) do not strictly require these access control methods. I'd like to see development happen in two stages. The first would be a simple device with FPGA only. This would provide a significant amount of functionality with a reasonably short developement cycle. A second stage could be the integration of a full CPU/OS and fully abstracted tuner API. Much, if not all, of the FPGA code developed for the first phase is directly applicable to the second, so the effort isn't wasted. > Why do you think you will not be able to embed the > frontend drivers from > the LinuxTV project into your network tuner device's > firmware...? I never said that. Of course this is possible. Running linux on one of the many ARM-based SoC out there would allow you to provide not just the tuner API, but also IP-decapsulation, http configuration pages, and other things. But at that point you're designing a full media receiver, which is a larger scope than what I had in mind originally. Regards, Brian __________________________________ Discover Yahoo! Have fun online with music videos, cool games, IM and more. Check it out! http://discover.yahoo.com/online.html
