Stephane Letz at GRAME, of JackOSX and jackdmp (multi-processor jackd) fame, has been working on a Windows port of JACK (specifically, jackdmp), and reports early initial success. We apparently need a new ASIO backend, and there is much other work to be done, but the basics appear to work satisfactorily. The original author of JACK is preparing to eat hats, crow and his own left foot as payment for all the times he said it could not be done. Watch this space for more information as it happens.
I hope to see an Haiku port 'cause it can help open audio software devs to release BeOS versions… :shock:
Basically, the media_server in BeOS/Haiku can probably already do this… or if not, it can most likely be modified to do this without porting another product. Since all BeOS apps use that for audio output already, there’s no need for another layer.
Edit: Oh, i see you are proposing that it be ported for the purpose of porting… something tells me that’s probably not the best way to get good audio apps in BeOS/Haiku - as the media_server is already very modular and powerful by itself… it would be a shame to put another layer in.
Well, the problem comed out in this 3ad @ Ardour forum (note: Ardour is a fully-featured digital audio workstation, similar to other software like ProTools, Nuendo, Sonar and Logic… an Haiku port would be really great, to me) talking about a win port:
paul wrote:
We didnââ¬â¢t do a Windows version for a long time because (a) JACK didnââ¬â¢t run on Windows, and I believed that it was impossible to make it work (b) Ardour relies on several basic POSIX APIs that Windows simply doesnââ¬â¢t support correctly.
…
Once the merge of the win32 branch is complete, we will be back to a single codebase for all 3 platforms, with very very few #ifdefs. In general, we try extremely hard to avoid platform specific code.
Anyway, JACK port isn’t the unique solution: a wrapper could be great too.
:roll:
Just a question: if media_server exist, what’s the meaning of PortAudio BeOS version ? :oops:
Just a question: if media_server exist, what's the meaning of PortAudio BeOS version ? :oops:
Same thing - just another cross-platform API for sound. This is an unfortunate side effect of open-source - many many people reinventing the wheel. BeOS has a beos-like media_server which is very modular and flexible - unfortunately it also requires code to be written for it.
In this way, if someone wants to port an audio-related application dependent on another API, it either needs to be adapted to BeOS media_server, or the API must be ported. The porting of the API is probably easier, but certainly doesn’t provide the best solution as far as performance, stability, and flexibility.
OpenAL is intended as an audio equivalent to OpenGL, it is aimed mostly at video games and it provides a hardware neutral API for 3D positional audio. Since it’s an open standard it makes sense to support this in any operating system hence the references to using OpenAL in Vista.
PortAudio and SDL are just wrapper libraries, they are portable APIs that hide differences between platforms. SDL does a lot more than just audio and is mostly aimed at video games again, while PortAudio has been used more for WAV editors and MOD players. Having PortAudio and SDL makes it easier to bring existing software to Haiku.
JACK is rather different. It’s not just an API, but rather a complete professional audio framework which only uses the host operating system’s raw audio device drivers for I/O. It was originally written just for Linux, and it was so popular with developers that they ported it to OS X and now apparently to Windows.
Most operating systems today provide a “system mixer” which makes it possible for many applications to share a single hardware sound device just as the window system allows them to share a single display. In Windows and the Unix Open Sound System this mixer is a kernel component, in the BeOS media kit or in ALSA on Linux it’s a userspace component.
The provided system mixer is a compromise by necessity. It sets an upper limit on the quality of the entire sound system, and imposes a latency penalty on all applications. This compromise makes it easier to write email apps that go “ding” when new mail arrives without needing to teach every developer about real time audio. For professional audio work such compromises aren’t acceptable, so JACK goes directly to the hardware, on Linux through the ALSA hw: devices, in OS X through Core Audio’s hardware access and in Windows through ASIO. If it were ported to Haiku it would use the raw driver interface to audio hardware, disabling the Media Kit’s audio support.
JACK is rather different. It's not just an API, but rather a complete professional audio framework which only uses the host operating system's raw audio device drivers for I/O. It was originally written just for Linux, and it was so popular with developers that they ported it to OS X and now apparently to Windows.
Hmm… interesting - I see the difference now.
Quote:
For professional audio work such compromises aren't acceptable, so JACK goes directly to the hardware, on Linux through the ALSA hw: devices, in OS X through Core Audio's hardware access and in Windows through ASIO. If it were ported to Haiku it would use the raw driver interface to audio hardware, disabling the Media Kit's audio support.
Ok, so basically it’s a trusted professional-grade hardware API… I suppose I can understand then why it couldn’t be adapted to the media_server as a wrapper directly.
Well, the problem comed out in this 3ad @ Ardour forum (note: Ardour is a fully-featured digital audio workstation, similar to other software like ProTools, Nuendo, Sonar and Logic... an Haiku port would be really great, to me) talking about a win port:
I think there's a lot better way of multitrack recording, like:
Each track is an audio node in Media server. The mixing will be done by media server, also audio routing VST plugins. Audio mixer could be just usual Be mixer app, or something like Cubase mixer, but it operates with standard Mediaserver controls. Also, for example, Cortex could be used for controlling audio routing.
In this way, writing multitrack recording software sould be pretty easy task, basically SoundPlay already does this, you couldplay multiple files simultanously with it.
I really think this is very beos-ish way - simple and robust, but still elegant and fast.
I think there's a lot better way of multitrack recording, like: (..)
I really think this is very beos-ish way - simple and robust, but still elegant and fast.
I can't find any (open source) multitack editor for Haiku/BeOS (except the old freeware Edison Cylinder which is no more developed/supported by its author) on the net, do you know any ?
Do you mean that adapting an existing app (Ardour, in this case) is more simple than porting JACK ?
What NoHaikuForMe said is dead on. If media_server can really do what Jack can do, then great. Otherwise, we need Jack in Haiku. BeOS was supposed to be ideal for media applications. Does media_kit have for example, MIDI routing? How about 192kHz sample rate? How about low latency?
Can this really be done? Are media_server’s algorithms clean? How wide is the path? 64bit? What kind of latency can we expect?
What you describe is how I use Jack to DJ. There are many nice little useful apps written for Jack that would not need to be rewritten for media_server, if indeed it is better for this.
I understand about wanting to keep layers down. However, as NoHaikuForMe pointed out, the basic sound layer/driver subsystem is usually crap, which is why we have things like ASIO etc…
I think you have it backwards… if media server cannot do what jack can do it should be improved so that it can. Using someone’s else’s API is always a bad idea as you no longer control the direction that API in your system will take in future revisions.
If the basic sound layer is crap then clearly its better to improve it rather than port a an alien driver system that will cause problems of its own.
For instance the reason a Mesa/Gallium3d port is wanted is that Haiku/BeOS doesn’t really support 3d at all… so there is nothing to build from however that is not the case with sound as there is already an API for that in existence that it at least seems people have liked.
BTW I doubt you will get a reply from anyone in this thread its is 3 years old after all and only NoHaikuForME and umcullough are active as far as I know.
PS
Are you suggesting we re-invent the wheel? Does the Haiku team have sound engineers? If not, I’d rather they not implement a half-baked solution and force us to code for it.
Anyone interested can see for themselves here why there are latency issues with Media-kit: