27 Jul
2006
27 Jul
'06
3:54 p.m.
Ismael Cortes wrote:
On 7/27/06, Renich Bon Ćirić
<renich(a)woralelandia.com> wrote:
LOL. Thanks for the links! I will read some on the topic.
James Courtier-Dutton wrote:
Renich Bon Ćirić wrote:
Well, everybody's telling me that Akai's OS is something else. Realtime
stuff and 2 or 3 engines and DSPs to manage. Besides, we have to support
akai's native file formats, like PROGRAM, MULTI and Sequence.
I really don't know why... I'm just hearing what everybody says. You
think
it shouldn't be that hard to port Linux and develop the effects and
stuff,
and to support Akai's native format? Would you give me some arguments
and
reasons?
Thanks for the input!
The datasheet you posted it nice a detailed. We would need
documentation
regarding the file formats, so we could implement support for them.
I think the biggest problem you will come up against will be getting
the
equipment and the open source developers together.
Unless you donate the kit to each developer, nothing will happen.
The kit
is far too expensive for a developer to purchase out of good will.
James
Is the kit totally necesary? Can we build an emulator out of the
service
manual? An emulator would be a natural step, i think. In any case, I
have
some questions about a post a friend of mine made to the forum where
it all
started. You can check it for yourself at:
http://www.mpc-forums.com/viewtopic.php?t=54825&start=60
but I will paste it here. Can anybody comment on it?
Guys,
Linux as it is ordinarily distributed is not a small-footprint
real-time
operating system. You will notice that your cell phone does not run
Linux.
There is a reason for that. There is also a reason that the MPC4000 is a
zero-latency device whereas a PC, even one running Linux, is not a
zero-latency device; it requires audio buffering and latency
compensation
and all that sh*t that drives people to work on an MPC in the first
place.
If you haven't designed a real-time embedded application before --
e.g.,
the software that controls a piece of machinery or electronics --
then you
are not in a good position to offer advice about how best to do this.
There are public-domain RTOSes available that are suitable for this
task.
To those, you can add drivers for USB and FAT32. Without an RTOS to
give you
hard real-time scheduling, you have no chance to achieve the rock-steady
timing that the MPC currently has.
-illiac
You've just made a huge mistake... you just told linux zealots that
linux is uncapable of something... now we are going to make it
possible... ;)
Anyway, you should read some stuff about linux and realtime. I agree
totally that linux is not a hard-realtime OS, and was never designed
to be such. So I wouldn't deploy it in a few places where QNX is king,
but it's still quite capable.
Here are a couple of links, it's your project, so it's totally your call:
* http://linuxdevices.com/articles/AT8211887833.html this is an
extract of a lkml message (available here
http://lkml.org/lkml/2005/6/7/256) which compares different ways of
achieving realtime in linux.
* http://www.realtimelinuxfoundation.org/ it's basically a bunch of
guys talking about how to make linux realtime, all the time. Check the
"Variants" and "Solutions" sections. There seem to be a few
hard-realtime solutions (unlike Molnar's patch, which gives you
soft-realtime), but they seem quite hard to implement... haven't tried
them, tho'.
Now, I'm going back to lurking mode...
Have fun!
Regards.
-Ismael C.