Err. Skipless. Need I say more?
> I've actually built a
> bunch of systems that were originally spec'ed to be hybrids. Wouldn't be
> surprised if Mark had too, given his Nortel address.
I hope that's not an invitation to a resume war. I built, or was instrumental
in building, a system that not only replaced a number of horribly expensive
motor regulators with software running closed loops over a realtime network,
but ran a gui, database, report generator, ladder logic, sensor inputs and
two-way network interface over serial lines, all on a 486. So I know what
it's like to do it all with a realtime system. I'd rather not, thankyou, not
the parts that don't need it.
> > Also, it appears you didn't read the post you responded to. Two alternatives
> > were presented:
> >
> > 1) Load the whole mp3 into memory before playing it
I'll leave that to people who appreciate quality mp3 playback to decide.
> And that alternative sucks. Think scalability.
>
> > 2) Implement a filesystem with realtime response
>
> And your shared fs alternative sucks. Think abysmal disk throughput for
> the rest of the system. Think starvation. Think all the reasons we've been
> trying to clean up the elevator code times ten. And that's just for the
> device queue, never mind the deadlock avoidance problems. See "priority
> inversion".
What kind of argument is that? It sounds like: because our current block
interface sucks, all block interfaces suck, and always will. On the
contrary, I believe our current interface sucks precisely because it is
not built according to sound principles of realtime design.
You seem to be all in favor of giving up before you start. That's not
how Linux was built.
> > Both approaches have their uses. The second is the one I'm interested in,
> > if that isn't already obvious. The first is just a quick hack that will
> > give you guaranteed-skipless audio playback, something that Linux is
> > currently unable to do.
>
> Umm, neither can your CD player. But if you take the proper precautions to
> avoid it being jostled, clean your discs, and give it decent buffering, it
> will be more than satisfactory. Can we bring Linux up to the same
> standard with the pre-empt and low-latency approaches?
No you can't. Grief.
-- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/