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

[Renich Bon Ćirić]

Ismael Cortes wrote:
> 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.
LOL. Thanks for the links! I will read some on the topic.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: renich.vcf
Type: text/x-vcard
Size: 289 bytes
Desc: not available
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20060727/c268c908/attachment.vcf>