I expect some interesting challenges with making the software work across several platforms. I have run real time Linux kernels some in the past. It certainly does change the way some applications behave. I think there will also be some interesting advantages with having working software on other platforms. I don't know what the approach is going to be for the Deep Impact software. I am hoping it will ultimately be in two parts. The time sensitive calculations dealing with signal decoding (and possibly using the fastest hardware, if the display side is detached over a network) and the display / user interface side of the application.
Writing an application for Linux or MacOS will have some interesting challenges. Ubuntu alone has gone through several release flavors in the past 2 years. The good news is that generally the changes made were an improvement. There has been at least one significant update to the RT kernel code that I am aware of since trying the FFADO drivers last year. I would like to see Linux code that could be used on more than one flavor of Linux. Once working code is pretty close I don't think that will be a substantial problem. Last time I tried compiling a kernel for a RedHat based box it was slightly different from Ubuntu, but not enough to be a significant problem. I am certainly looking forward for the DI project working. It will give me a reason to put the 5000A back on the air and keep my last remaining working XP machine doing what it does best (run old software). Dave KU4B On Tue, 2010-11-16 at 12:23 -0800, Jim Barber wrote: > I don't know that using the standard Linux kernel would be of that much > benefit at all. The chances of ending up with squirrelly, slap-dash or > otherwise broken device drivers *for other hardware* is at least as > great as with Windows. > > Now on the other hand, "realtime tweaked" kernels in distros like Ubuntu > Studio handle low-latency audio quite well, assuming everything works > well out of the box. Will it? Good question. > > I won't argue the fact that Windows is a huge PITA for low-latency or > near-realtime operation with ANY external hardware. I'm just not sure > that Linux, MacOS or any other low-cost system available to the masses > will be the panacea it appears some are expecting. Is Flex going to > maintain a qualified hardware list and driver archive for xyzOS? > Probably not. > > Now... For the Rugged Individualists in the group and perhaps GEN-1 and > later geeks, I ain't talkin' about you so don't get upset! ;-) > > My .02, > Jim N7CXI > > On 11/16/2010 12:01 PM, Jack Haverty wrote: > > Moving from one OS to another won't necessarily make it better, but it > > will be almost certainly different. > > > > DPCs are a Windows thing - it refers to how hardware interrupts are > > handled, and what processing is done "in real time" when an interrupt > > happens versus done later (deferred) when the O/S gets around to it. > > > > However, I think all OSes have a mechanism analogous to DPCs. So the > > problems associated with DPCs can happen in any OS. > > > > "Device drivers" are usually pieces of software with 2 components. One > > runs asap when the hardware interrupt triggers it, and how quickly it > > runs depends on things like bus contention, IRQ sharing, etc. OSes > > can't do much about that, it's associated with the specific hardware. > > > > When the device driver runs, what it is allowed to do, and what it is > > recommended to do, is determined by the O/S architecture - e.g., how the > > O/S prioritizes processes, what "hooks" it provides to drivers, the > > algorithms the scheduler uses, etc. > > > > Generally, you want that first piece of code that runs on interrupt to > > do only the absolute minimum that is needed to happen right away, such > > as reading data from a hardware buffer before it gets overwritten by the > > next incoming data. While this software runs, nothing else can run, > > except maybe a "higher priority" hardware device. All other processing > > should be "deferred", to be run when the O/S scheduler decides it's > > time. > > > > Problems occur when things don't happen as soon as they need to. Input > > data gets dropped, buffers overflow, etc. > > > > How bad that is, on identical hardware, depends on how well the O/S > > juggles competing priorities, as well as on how well the people writing > > device drivers follow the rules. If a particular driver spends too > > much time when it has control of the CPU, other drivers lose out. > > > > Different people write drivers for Windows, Mac, Linux, etc., or at > > least there are different versions, because the environment provided by > > the OS is different. So the behavior will be different, on the same > > hardware, depending on the OS used. Some programmers are more skilled > > than others. > > > > Writing good device drivers is an art, and a difficult one at that. > > Writing simple device drivers, that work for your device but can cause > > all sorts of problems for others, is much easier, and it gets the > > product out the door faster. > > > > Linux gets used in a lot of lab environments, real time data > > acquisition, etc., so those kinds of drivers are likely well tuned. > > Windows gets used in a lot of home and office environments, with > > multimedia, graphics, etc, so those kinds of drivers are likely well > > tuned. > > > > Changing OSes probably won't solve all problems, but it will make a > > difference. > > > > 73, > > /Jack > > > > > > On Tue, 2010-11-16 at 10:56 -0800, Brian Lloyd wrote: > >> On Tue, Nov 16, 2010 at 10:37 AM, Frank Goenninger<[email protected]> wrote: > >> > >>> Am 16.11.2010 um 19:32 schrieb Brian Lloyd: > >>> > >>>> On Tue, Nov 16, 2010 at 10:26 AM, Jack Haverty<[email protected]> wrote: > >>>> > >>>>> I use Debian, which I think is still the same genetic code as Ubuntu. > >>>>> Debian has lots of 1394 software, for disks, video devices, etc. None > >>>>> of my Linux machines have a 1394 card, but that's easy to fix. But if > >>>>> "driver" means the code that connects dttsp to the kernel 1394 device > >>>>> and knows the Flex language used on that device, it's quite possible > >>>>> that hasn't been written. But I think the kernel drivers are there. > >>>>> > >>>>> I agree -- if anyone knows otherwise... > >>>>> > >>>> > >>>> Has anyone considered the possibility that the kinds of DPC latency > >>> problems > >>>> (which seem to be hardware related) might apply in Linux and other OS's > >>> when > >>>> run on the same PC hardware? > >>> > >>> Well, my experience is that you just don't have latency problems at the > >>> speeds (192kHz) FRS is using as a maximum. Iff you connect two or more FRS > >>> devices then the Mac Mini might get in trouble. That's what I see from > >>> using > >>> multiple professional sound interfaces and sequencer software on it - all > >>> running in OS X of course. Windows presents problems others simply > >>> haven't. > >>> > >> > >> I have had the same experience with Apple and sound devices. (Apple has > >> spent a lot of time making sure that FireWire devices work well with > >> MacOS.) > >> > >> Still, I was referring to generic PC hardware mostly running Linux. There > >> seem to be a lot of people assuming that just moving the Linux from Windows > >> will solve all the problems and I am not sure that will be the case. The > >> hardware that induces DPC latency problems still exist on that hardware > >> regardless of the OS running on top of it. > >> > >> Don't get me wrong, I would love to move to a different software platform. > >> Most of my stuff is MacOS but I would much prefer even Linux over Windows. > >> Still, I don't want people to just assume that changing OS's will solve all > >> the problems, especially those that are down at the hardware level. > >> > >> > > > > > > > > > > _______________________________________________ > > Flexedge mailing list > > [email protected] > > http://mail.flex-radio.biz/mailman/listinfo/flexedge_flex-radio.biz > > This is the FlexRadio Systems e-mail Reflector called FlexEdge. It is used > > for posting topics related to SDR software development and experimentalist > > who are using beta versions of the software. > > > > _______________________________________________ > Flexedge mailing list > [email protected] > http://mail.flex-radio.biz/mailman/listinfo/flexedge_flex-radio.biz > This is the FlexRadio Systems e-mail Reflector called FlexEdge. It is used > for posting topics related to SDR software development and experimentalist > who are using beta versions of the software. _______________________________________________ Flexedge mailing list [email protected] http://mail.flex-radio.biz/mailman/listinfo/flexedge_flex-radio.biz This is the FlexRadio Systems e-mail Reflector called FlexEdge. It is used for posting topics related to SDR software development and experimentalist who are using beta versions of the software.
