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.
