[linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project

[Ismael Cortes]

On 7/27/06, Renich Bon Ćirić <renich at woralelandia.com> wrote:
>
>  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.