OSDev.org

I'm looking for an Ada or C/C++ developer. Target project is an Operating System written mostly in Ada. Operating system is to be designed for Professional Audio uses, such as recording, and live performances.

The license has not been decided, I am leaving it up to any developers willing to help out to make that decision.
Hardware experience is not required.
Other languages are possible, but you would have to justify them (don't worry, I'm rather open).

The biggest reasons behind this project are:

The most destructive thing to general audio, is high latency, and improper receiving of the analog form, which mostly go hand in hand. Good receiving is achieved by developing good hardware and software architectures for handling audio. This has already been done for hardware, and I have little complaints here (silver should be used instead of gold, is about it... woo...). The second most destructive thing to general audio is any bugs that might happen, either in hardware or software. While this is second generally, a bug can devastate a performance, especially during technical areas like solos, or complex melodies/harmonies... you get the point. It's always possible to beef up speed to make up for the slight speed differences, but Ada does have a hell of a lot more about it, that helps avoid such issues. This is more directed to prevent various mishaps resulting in death, but Ada still is a general purpose language.

And personal distress with some digital effects that have failed on me, or issues in digital recording that don't exist when recording analog. Seeing as analog has some serious pitfalls, I would like to do away with as many of digitals pitfalls that aren't actually related to the digital nature. That is, doing away with architectural flaws in the software side of recording setups.

There is a wealth of information, and elaboration in the posts below. I would strongly recommend reading them, not only are they informative, but they do a great job explaining in detail why this project exists, and what its goals are. Sorry if they are a little long, this isn't a simple project.



If interested, please fill out the attached text/plain file and send to [email protected].

What are the payment rates?

Combuster wrote:What are the payment rates?

Well that would ultimately depend on what license it gets released under, and what is decided to be done with the software.

I'm doing this more as a musician, than as a developer. The resume was mostly there so I could get any information I needed without people sending me half of what I needed, and having to send another e-mail back of what else I need to know, to every person. If you look at it, you can tell it lacks most things a formal resume have.

If it's decided the software would go commercial, then some payment method could be drafted. My primary goals aren't money though.

Why Ada? Why is an entirely new OS required for audio recording? Why would a developer join you? Why is the licence not yet decided? Why are payment rates not defined? Why should we trust you, what have you done? Do you have any experience in the OS development sector?

The above questions are rhetorical and non-exhaustive.

EDIT: Just read the resume document:

Processor Your Most Familiar with: -- only one
Processors You've Worked on/with: -- list all

DSP Your Most Familiar with: -- only one
DSP's You've Worked on/with: -- list all

What's "processor" here? Type of x86 (nehalem, barcelona, ...)? Architecture (x86, POWER, MIPS, ...)? Why would normal software developers have experience with digital signal processors? They aren't general purpose!

General sentiments: Oh dear me.

-Why Ada? -- I'm not a fan of C. Theres no reason it has to be all in Ada. Likewise, theres no reason it can't use C.

-Why is an entirely new OS required for audio recording? -- You ever record professionally? You ever use digital equipment on stage? There's issues that I would like to fix. Did I say an entirely new OS would be needed? Did I say that no code was reusable? I don't think I did, if I made it seem that way, then sorry.

- Why would a developer join you? -- Who knows, may be they find this interesting.

- Why is the license not yet decided? -- People can sometimes be picky on how they license their code. I left it open, so that if other people were interested in the project, a license could be agreed upon.

- Why are payment rates not defined? -- Why does this have to be commercial? Why can't this be a project to make something better, not make money? Greed is a notoriously bad thing.

- Why should we trust you, what have you done? -- I'm going to assume you mean in terms of development. Mostly work on Audio hardware, usually dealing with analog or digital effects (foot pedals). For software, I've done a lot of micro-controller related work, wrote a hefty sum of VST, VSTi, DSSI, LADSPA... plugins. I've done some minor work with the ALSA.

- Do you have any experience in the OS development sector? -- Outside of micro-controller related systems, not really. Some minor contributions here and there, but it's been minor.

- What's "processor" here? -- Sorry, I should have elaborated, It is processor architecture, so MIPS, POWER, BLACKFIN, x86...

- Why would normal software developers have experience with digital signal processors? They aren't general purpose! -- Very true. But since you've been so lovely and accepting of me, why don't I return the favor? You've clearly never done anything related to low level audio. DSP's are basically required in the processing and manipulation of audio. If you don't believe me, check out a personal favorite of mine. http://www.freescale.com/webapp/sps/sit ... 0127955654. If the system is being written purely for Audio related reasons, why would using a DSP be bad? More over, why can't you have both a Proc and a DSP? TI and Freescale seem to have no problem doing this.

Why do you immediately assume so many things? I've never said that everything had to be written from scratch. I never said anything about pay, quite frankly I've never seen anything about money on these forums.

kameo76890 wrote: Why do you immediately assume so many things? I've never said that everything had to be written from scratch. I never said anything about pay, quite frankly I've never seen anything about money on these forums.

You said you wanted to write an operating system for audio processing. Not a linux distribution or something to that effect.You should really give more info on the first post of a project. Here, we all assume the worst because it typically is. I think you underestimate how many people come here with posts like

I want to make an OS. It will be able to run windows stuff but it'll look way better. I just picked up a book on C and I'm designing the graphics for it. Could anyone help me with the programming of it? It shouldn't be too hard

Oh I do understand how many people want to do things like that. Everyone wants the next Windows or Mac. I'm merely doing what I learned from being a musician, find a niche a fill it. There aren't any outstanding systems for recording or performances, thats what I'm targeting.

Yes I did say I was going to write an operating system, I didn't say I was going to write the whole thing. The parts that I'm `worried about/most interested in` is related to audio. Meaning that only the kernel and audio related frameworks need to be done specially. Who cares if some of BSD's tools or networking stack are used, that doesn't effect audio. Although it could be any other tools, I don't really care. Like stated so many times, my focus is better audio, after that I don't care how its done.

Hi,

Apologies if I seemed abrupt. My observations were and are intended to weed out those people who have just not thought things through, of which sadly there are plenty.

The points I'm not so sure about:

-Why Ada? -- I'm not a fan of C. Theres no reason it has to be all in Ada. Likewise, theres no reason it can't use C.

That's really not a fantastic reason to use Ada. Ada is a gigantic pain-in-the-arse, and was designed that way. Because its compiler is so strict, writing an OS kernel in it (which generally involves a lot of pointer manipulation, casting and bit-twiddling in general) is going to be difficult. I know, because I've written a real-time operating system in it.

Not only that, but you have to first get the Ada runtime booting, which is a lot of work if you don't use a COTS solution like MarteOS.

- Why would a developer join you? -- Who knows, may be they find this interesting.

The reason I mentioned this is because in your original problem description you were *very* specific about what skills the ideal "candidate" would have, yet you didn't discuss remuneration. Generally people need quite a compelling reason to volunteer their time, such as a specific plan of action.

- Why would normal software developers have experience with digital signal processors? They aren't general purpose! -- Very true. But since you've been so lovely and accepting of me, why don't I return the favor? You've clearly never done anything related to low level audio. DSP's are basically required in the processing and manipulation of audio. If you don't believe me, check out a personal favorite of mine. http://www.freescale.com/webapp/sps/sit ... 0127955654. If the system is being written purely for Audio related reasons, why would using a DSP be bad? More over, why can't you have both a Proc and a DSP? TI and Freescale seem to have no problem doing this.

I don't disagree that DSPs are used a lot in audio processing; and I don't disagree that I've never done anything related to low level audio. I however clearly am not writing this post on a forum about low-level audio signal processing, so hopefully you see my point

I.e. finding an Ada developer with DSP experience who'll work for free is going to be a hard task; maybe you should widen your criteria a little?

(not to mention that if I were to develop an audio-processing app using a DSP, I'd be quite tempted to use Handel-C and stick it on an FPGA for speed).

Um, what is your "exact" platform for this? A PC or some hardware in audio processing stuff or homebrew stuff?

If not running on a computer, you would probably be better just ripping off some RTOS that is already out there..

Be careful with how you use fantastic. When looking at the rest of your points, you actually should say my reasons for using Ada ARE fantastic. Unfortunately people tend to have the definition of fantastic somewhat off, not really a big deal.



On a more serious, and to the point, note, I feel the opposite you do towards languages. I actually find C/C++ to be a pain. Saying Ada was designed to be a pain-in-the-arse is a rather bold statement too . I'm completely fine with the strictness of Ada, and have problems with the looseness C provides. Everything I've done, tends to just work better when I do it in Ada. May be that's just me, but I think everyone would agree, if it works better, do it. I do understand the majority of people do better work in C/C++ than Ada, which is why I was being open about languages, but I just prefer Ada. -- Is it possible to change the thread topic to include C/C++, since I technically don't care?

I have a decent collection of Ada components related to real-time systems present from older projects. Some might need modifications, the majority are probably too tied to a specific task to be used, but I am used to Ada for low level components.


I'm sorry if those seems like criteria, I was just getting any relevant information. Say for instance, someone has no experience with low level parts, but has a good reputation in audio toolkits, there's little reason they couldn't help out. The same thing works the other way around.

Yes may be I should get more specific, It would seem most criticism I've gotten has ultimately been from not giving enough detail, or not elaborating enough.

I could very easily pay additional developers. I could very easily pay my own workers to do this. Personally, I'm doing this to better something, I couldn't care about the money. That is why I want to leave the licensing up to anyone wanting to help. If it winds up being just me writing this, then most of the code will probably go into the public domain.

The most destructive thing to general audio, is high latency, and improper receiving of the analog form, which mostly go hand in hand. Good receiving is achieved by developing good hardware and software architectures for handling audio. This has already been done for hardware, and I have little complaints here (silver should be used instead of gold, is about it... woo...). The second most destructive thing to general audio is any bugs that might happen, either in hardware or software. While this is second generally, a bug can devastate a performance, especially during technical areas like solos, or complex melodies/harmonies... you get the point. It's always possible to beef up speed to make up for the slight speed differences, but Ada does have a hell of a lot more about it, that helps avoid such issues. This is more directed to prevent various mishaps resulting in death, but Ada still is a general purpose language.

I have no idea what Handel-C is

I stand by my "not fantastic" statement. The reason you gave was "not a fantastic reason" to use Ada over C. You've subsequently (last post) given much better reasons, which make a lot of sense.

Honestly, the advantages I see with Ada (massive type-safety, excellent inter-thread (task, in ada-speak) communication) aren't the biggest problems in your design that needs solving. Writing a DSP requires very fast code, which isn't generated by current Ada compilers (GNAT); This is why I would use C/C++ for this project. However, that is just what I would do, and means nothing to this thread

Handel-C is a hardware description language that is designed to look similar to C. It is not C - every statement gets executed on a new clock cycle and hardware is generated to perform each statement /function call. It's much more rapid than coding in VHDL!

If I were creating something so latency-sensitive, I'd personally go down a layer and implement it in hardware. The Spartan FPGA development boards have DSPs included, and hell, if you need to run some algorithm that would be expensive in hardware, it takes around 20 lines of Handel-C to create a simple softcore processor.

Fast fast fast

earlz wrote:Um, what is your "exact" platform for this? A PC or some hardware in audio processing stuff or homebrew stuff?

If not running on a computer, you would probably be better just ripping off some RTOS that is already out there..

My exact platform would probably be the MIPS or Blackfin and the Symphony. If someone has a compelling reason to use something else I'd be happy to consider it, but those tend to work best for me in benchmarks and in practice.
No this would not be a PC, when the PC came out, recoding wasn't on IBM's mind. While it's gotten better over the years, the PC architecture isn't the greatest for those tasks. Now I'm not saying the parts related to the PC are flawed for this task, there are parts that work just fine; I'm referring to the PC as a whole. Home-brew wouldn't be the right term. While yes I guess technically my personally designed foot pedals have had a "home-brew" design, it wouldn't be appropriate to call this project home-brew. The goal of this project is to create better ProAudio tools, both for recording and performance, but on the software level. Like I said, the hardware is generally fine. Now I guess since I just said the PC has it's flaws, a different type of machine would have to take its place, but that is outside the scope of this project.

- If not running on a computer, you would probably be better just ripping off some RTOS that is already out there.. -- How could one run software on a something other than a computer? What else would it run on? Regardless of whether it's a CPU, GPU, PPU, uC, DSP or even a basic transistor array, it's still doing computing. On a non-critical note, a RTOS wouldn't be able to handle the recording side of things, which is half of the reason I'm doing this in the first place. An RTOS would work fine for the performance related side, but they are not designed with audio in mind, there are many, many similarities, but the design goal ultimately differs. It would work, but it's not the best solution, kind of like using a car to tow, rather than a truck.

JamesM wrote:I stand by my "not fantastic" statement. The reason you gave was "not a fantastic reason" to use Ada over C. You've subsequently (last post) given much better reasons, which make a lot of sense.

Honestly, the advantages I see with Ada (massive type-safety, excellent inter-thread (task, in ada-speak) communication) aren't the biggest problems in your design that needs solving. Writing a DSP requires very fast code, which isn't generated by current Ada compilers (GNAT); This is why I would use C/C++ for this project. However, that is just what I would do, and means nothing to this thread

Handel-C is a hardware description language that is designed to look similar to C. It is not C - every statement gets executed on a new clock cycle and hardware is generated to perform each statement /function call. It's much more rapid than coding in VHDL!

If I were creating something so latency-sensitive, I'd personally go down a layer and implement it in hardware. The Spartan FPGA development boards have DSPs included, and hell, if you need to run some algorithm that would be expensive in hardware, it takes around 20 lines of Handel-C to create a simple softcore processor.

Fast fast fast

Fantastic
1 a: based on fantasy : not real. b: conceived or seemingly conceived by unrestrained fancy c: so extreme as to challenge belief : unbelievable; broadly : exceedingly large or great.
2 : marked by extravagant fantasy or extreme individuality : eccentric.

-- Thats why it would make more sense for my statement to have been viewed by you as fantastic.


English Aside...
GNAT isn't the only Ada compiler, while it may the main, and dominant one, there are others. A whiles back, I wrote an Ada compiler much better suited to this area. Not just that, but you can disable the runtime checks, which significantly improves code performance, although that would go against a reason for using Ada.

I see, I will have to check into Handel-C. Be careful with the "less lines"="faster" paradigm I'm fairly certain most scripting languages use less lines than C or Ada require. Although I'm not familiar with Handel-C so I'm just saying in general, I see a lot of people make that assumption.

If your implementing an audio modification algorithm on a FPGA, you might as well just go one step further and create an analog array. I don't quite know why, but modifying audio on a FPGA causes some weird issues. Now may be I don't know enough about FPGA's and how to implement and audio routine on one (I don't think anyone does), but I've had no luck. I'm going to play around with CPLD's sometime and see how well they do.

Wikipedia wrote:A CPLD has a somewhat restrictive structure consisting of one or more programmable sum-of-products logic arrays feeding a relatively small number of clocked registers. The result of this is less flexibility, with the advantage of more predictable timing delays and a higher logic-to-interconnect ratio.

-- More predictable timing delays is a plus, and might be why FPGA's have some trouble.

I've got the general idea on what to use the DSP for in regards to performace. When recording comes into play, I'm not quite sure if a DSP would still cut it. I believe it would, but there would have to be a DSP per mono input. Most instruments use monaural channeling, so this isn't problematic, it just means up to 32 DSP's on a device . The biggest issue comes into play when when you go about using multiple effects, like you would use in any studio, I'm not sure a DSP per signal could cut it. I'm thinking a Co-processor might be a better solution in that situation, I don't know if that would be a CPU or a CPLD yet. But thats hardware issues, and isn't the main goal of this project.

This is really beyond my expertise.. Are DSPs expensive?

Have you considered a massively parallel approach? I know very little about audio processing.. but the way I see it, if you could have say 32 slower processors(say for instance AVRs), wouldn't that help quite a bit than 1 super fast(and expensive) processor? or am I getting it wrong

earlz wrote:This is really beyond my expertise.. Are DSPs expensive?

Not really, especially if your buying in bulk. I've got plenty of different DSP's that didn't get used from other projects at work. I could use them for testing, but can't legally let others use them, I could sell to them, but it'd be at the same price as you can buy them for anyways.

earlz wrote:Have you considered a massively parallel approach? I know very little about audio processing.. but the way I see it, if you could have say 32 slower processors(say for instance AVRs), wouldn't that help quite a bit than 1 super fast(and expensive) processor? or am I getting it wrong

Kinda-sorta, as you should know, not everything benefits from parallelism. That's why the "war" between the SPARC and the POWER is bull ****. Audio can be weird in that it does benefit from parallelism, but still requires raw power. It's a bad example because the x86 is horrible for audio, but if you look at how the x86 sits in between the SPARC and the POWER, you get an idea of what I'm talking about.

I guess the best way to explain the hardware architecture (for recording) would be something similar in theory to the CellBE, a central CPU, probably the MIPS, although POWER is also feasible. This would then utilize various Co-processors, ideally I would like those to be DSP's, although if they can't be, the MIPS seems to be the best option, although I still haven't tested CPLD's. Now in this situation, everything wouldn't be on a single chip, much more like the multi-GPU system CUDA or OpenCL developers use. Actually that multi-GPU model is rather fitting, just instead of video cards, its more like sound cards. Hardware is outside the scope of this project though. I'd like to keep it as hardware independent as possible. Unfortunately it's beginning to look like this might be very tied to hardware.


By the way, at the time of this post, your Posts = 1337, which kinda made me laugh.