Professional Sound API
I'm interested to know what API model Haiku will be implementing to allow professional sound applications to be written.
On Windows we have a variety of API's such as WDM from Microsoft, ASIO and VST/VSTi from Steinberg and Rewire from Propellarheads. On apple we have AU and Jack OSX and on Linux we have quite a few but the best appears to be Jack and ALSA. There are other ones from Pro Tools too.
So on Haiku what's it going to be?
A professional level sound API must be low latency to allow realtime dsp of audio and allow the audio to be routable between hardware and software and between software and software etc.
Obviously the appeal of Haiku is it's ultrafast use of multi core processing and it's heritage coming from BeOS, the media OS.
I'm not too concerned about midi since this appears to be already done and in the API, but what about sound? I noticed OSS has come along but is this the best on offer? I realise that hardware support is needed and it seems to come with alot of driver support. But what I am talking about is professional level implementations for IO, routing and dsp processing.
So what are the long term goals for getting audio up to scratch in Haiku and will this become part of Haiku for professional sound and have it's own native API.
Comments
Re: Professional Sound API
12msec is
0.00012 seconds
Isn't that supposed to be 0.012 seconds?
Regards,
James
Re: Professional Sound API
o whole .0 tenth 0 hundredth 0 thousand 0 ten thousand
Yeah I misplaced the decimal and its still faster then you blink.
Re: Professional Sound API
Why? Because JACK is capable of executing the effects in the "correct" order, while the media kit does not take the order of effects into account. So the media kit has to use past buffers for each effect to avoid processing bad data, and each buffer is 3 ms long.
Where did you read that the media kit doesn't take nodes chain order into account!?
Of course it does. Otherwise, why all these efforts to manage nodes graph, downstream latencies, notify late events, etc?!
In fact, in live run mode, all nodes in the chain are driven by performance time: each node is *called* at performance_time - this_node_downstream_latency - this_node_processing_latency - scheduling_latency
The minimal performance time being:
now
+ initial latency (in your example, the physical sampling latency, 3ms)
+ sum of all nodes processing latencies
+ sum of all nodes scheduling latencies.
Aka exactly like under JACK, except for scheduling latencies (see below how it's taken care of).
Maybe one confusion is that in Media Kit physical input are also nodes, and this initial latency is just the processing latency of this physical input node: for obvious reason, 3ms live sampling will take 3ms whatever the audio framework... But passing down this 3ms long buffer from nodes to nodes don't take 3ms, thanks god! What it take is just passing the buffer pointer, like JACK cycle task pass samples pointer to his clients.
The Media Kit neither enforce neither add arbitrary buffering (and so latency) between nodes. When all the nodes works on the same data format and rate, the same input sample buffer (in shared memory) is reused by every node along the chain, and no extra buffering is either needed or enforced.
What works because JACK enforce 32 bits float sample format and a common rate works the same under Media Kit.
JACK works synchronously on a fixed sample format at a shared (hence the synchronous) rate.
While Media Kit works asynchronously in term of processing model, the above situation is still supported in term of data flow model. But it's only one of the many data flow it can support. If you've follow the jackdmp design changes, you'll see that sequential activation is not the best design to benefit the most from SMP machines, hence why jackdmp (now JACK2) has to introduce parallel cycle(s) execution, working on previous cycle(s) buffer(s).
Which is far more similar with the data flow graph asynchronous activation strategy used by the Media Kit than one would think at first...
One issue of the asynchronous processing model is the scheduling latency of each node in the chain, which could cumulate contrary to the JACK's synchronous one. That's why the Media Kit monitors scheduling latency and automatically compensate drift by calling nodes early. JACK don't have to do that, because it's a RT task, which by definition have no scheduling latency drift.
On the other side, the more SMP capable your machine is, the less scheduling important latency & drift you will see ;-).
The eternal synchronous real-time processing vs parallel soft-time processing debate still goes on...
Re: Professional Sound API
Aka exactly like under JACK, except for scheduling latencies (see below how it's taken care of)
Thanks for clearing this up.
What works because JACK enforce 32 bits float sample format and a common rate works the same under Media Kit.
I'm not sure if that's a helpful way to think about it. AFAICT: The actual Haiku source and sink nodes are integer based. The actual system mixer does not adapt to use the same period size as the source. So "the same" does not seem to exist today on Haiku, unless I've missed something.
If you've follow the jackdmp design changes, you'll see that sequential activation is not the best design to benefit the most from SMP machines, hence why jackdmp (now JACK2) has to introduce parallel cycle(s) execution, working on previous cycle(s) buffer(s).
Which is far more similar with the data flow graph asynchronous activation strategy used by the Media Kit than one would think at first...
I think you're mistaken about the effect of the "pipelining" in jackdmp, or at least your description is misleading. The pipeline divides up periods at the source. So setting a period of 1024 frames has the same effect as before - and the same latency, but by processing a fraction (say 256 frames) of the period at a time jackdmp achieves greater parallelism at a cost of increased overheads. Is the Media Kit's scheduling equipped for this? Both the first 256 frames and the last 256 frames of a period must be delivered for the same deadline.
That's why the Media Kit monitors scheduling latency and automatically compensate drift by calling nodes early.
References to running things "early" predominate in discussion of the Media Kit, even by Be. But this only makes sense for the nice easy cases like "user is listening to some music files". I recommend that anyone working on Pro Audio solve the hard problem first, and that's real time audio. In real time audio there is no "early". We can see this in JACK's "race to idle" approach. A sound card generates an interrupt indicating that the last period is recorded into the buffer, this is the source. JACK runs the source buffer through the graph and writes it to the sink, which may also be a hardware buffer on the same sound card. It is not possible to compensate for anything by doing something "early" here, until the interrupt fires there is no audio buffer available with which to do anything.
Re: Professional Sound API
What works because JACK enforce 32 bits float sample format and a common rate works the same under Media Kit.
I'm not sure if that's a helpful way to think about it. AFAICT: The actual Haiku source and sink nodes are integer based.
Not true. The audio physical input and output are handled by MultiAudio node, which support any audio format (8/16/32 bits integer or float) that the below kernel hardware drivers supports. If they don't support float in hardware, someone must convert it somewhere in the pipeline. It's true for JACK sources and sinks too. The difference is that the Media Kit don't enforced a format and the system audio nodes supports all formats to be able to accommodate any situation. The actual format is negociated between nodes at connection time. If a node only support integer, but some other downstream node support only float, I fail to see how JACK or Media Kit can avoid the format conversion. Claiming that JACK works in float even with hardware working only in integer is wrong: the driver does the conversion, that's all.
Same with Media Kit, except that it can be anywhere, not only at input driver level.
With hardware working in float format directly, a Media kit pipeline can perfectly works in float format, including the MultiAudio and Mixer system nodes.
The actual system mixer does not adapt to use the same period size as the source. So "the same" does not seem to exist today on Haiku, unless I've missed something.
First, it's the default system mixer, but nothing forbid a pro audio solution to shortcut it totally.
It's just a matter of routing choice to make. Desktop multimedia apps routes their audio toward the system mixer because it make sense, but nothing forbid to route it toward a dedicated sink node instead. If one would want to mimic the JACK pipeline with the Media Kit, he would have to do that in fact, as JACK don't enforce either a system wide mixer client, AFAICT.
Second, the default system mixer time source is set to it's default output clock rate, indeed, simply because this rate can be totally disconnected from the input ones (multi inputs, not all physical). But it doesn't means that it's impossible to connect a chain of source -> effects nodes -> sink as in JACK pipeline and set the sink node time source being the source one.
It just doesn't make sense for a desktop operating system's default system mixer to do that, because the source(s) to mix can be anything, not only physical ones, and can have each one a distinct rate (and format, as seen above). On this regard, our Haiku system audio mixer must adapt the same constraints than PulseAudio one for instance.
But it's not because the default Haiku Media nodes are setup like they are that it means the Media Kit can only support such "default" setup.
I think you're mistaken about the effect of the "pipelining" in jackdmp, or at least your description is misleading.
Wont be surprised, as english is not my native language :-)
The pipeline divides up periods at the source. So setting a period of 1024 frames has the same effect as before - and the same latency, but by processing a fraction (say 256 frames) of the period at a time jackdmp achieves greater parallelism at a cost of increased overheads.
Well, what I saw in JACK2 design documentation was about parallel clients activation (aka process parallelism) when the graph have client waiting on more than one client. I didn't see the data subset parallelism (aka dataset pipelining).
Thanks to your comment, I've read a bit more and see your point here.
Is the Media Kit's scheduling equipped for this? Both the first 256 frames and the last 256 frames of a period must be delivered for the same deadline.
Nothing forbids a Media Kit node to divide his input buffers and produce sub-buffers at an higher rate to help similar parallelism of downstream nodes. The main differences here are:
- the media kit don't enforce such splitting mechanism, nor provides support to help a node coder to do it automatically. It's up to each node to do it how it's best for him (or his downstream nodes), and usually when it does it's at format negociation during connection phase: the buffer size, frame rate and sample count are all parts of the negociated format.
- *every* Media Kit node is *already* enforced to work in parallel: they're spawned as distinct threads, they can't avoid it. The JACK sequencial execution cycle model doesn't exists at all in term of Media Kit land, instead you'll have a pipeline of producer/consumer threads. If an upstream node decide to divide the input frames on output, all downstream nodes will automatically benefits from smaller latency by running in parallel on smaller frames.
In real time audio there is no "early".
True. In real time digital multimedia, strictly speaking, there is only "late".
The issue is to keep it under control.
While algorithmic latencies can't be compensate without degrading in some way the output indeed, scheduling latency could on SMP machines, by being parallelized.
When every node could run (theoretically) in parallel, instead of cumulating the schedule latency between each ones you could preroll the nodes. You have then just the initial nodes scheduling latency, the ones which make real time audio always late whatever you could do :-).
In the end, keep in mind that the Media Kit has to be far more flexible that JACK, who knows it's only audio 32bits samples, while the Media Kit has to support variable audio *and* video formats. Being flexible doesn't mean that it's not up for some very specialized task, it means it need far more setup and tuning to be able to it. Aka being specialized.
I'm not saying Media Kit is able to do everything JACK succeed to for audio, being the well-optimized for audio real time processing JACK is.
What I'm saying is that Media Kit was not designed to support only the playback usual case, which you seems to assert. In fact, if it was the case, it would be an overly flexible layer to accomplish just that. This flexibility is there for a reason: to adapt to more than one well-known case.
Re: Professional Sound API
What works because JACK enforce 32 bits float sample format and a common rate works the same under Media Kit.
I'm not sure if that's a helpful way to think about it. AFAICT: The actual Haiku source and sink nodes are integer based.
Not true. The audio physical input and output are handled by MultiAudio node, which support any audio format (8/16/32 bits integer or float) that the below kernel hardware drivers supports. If they don't support float in hardware, someone must convert it somewhere in the pipeline. It's true for JACK sources and sinks too. The difference is that the Media Kit don't enforced a format and the system audio nodes supports all formats to be able to accommodate any situation. The actual format is negociated between nodes at connection time. If a node only support integer, but some other downstream node support only float, I fail to see how JACK or Media Kit can avoid the format conversion. Claiming that JACK works in float even with hardware working only in integer is wrong: the driver does the conversion, that's all.
Same with Media Kit, except that it can be anywhere, not only at input driver level.
With hardware working in float format directly, a Media kit pipeline can perfectly works in float format, including the MultiAudio and Mixer system nodes.
The actual system mixer does not adapt to use the same period size as the source. So "the same" does not seem to exist today on Haiku, unless I've missed something.
First, it's the default system mixer, but nothing forbid a pro audio solution to shortcut it totally.
It's just a matter of routing choice to make. Desktop multimedia apps routes their audio toward the system mixer because it make sense, but nothing forbid to route it toward a dedicated sink node instead. If one would want to mimic the JACK pipeline with the Media Kit, he would have to do that in fact, as JACK don't enforce either a system wide mixer client, AFAICT.
Second, the default system mixer time source is set to it's default output clock rate, indeed, simply because this rate can be totally disconnected from the input ones (multi inputs, not all physical). But it doesn't means that it's impossible to connect a chain of source -> effects nodes -> sink as in JACK pipeline and set the sink node time source being the source one.
It just doesn't make sense for a desktop operating system's default system mixer to do that, because the source(s) to mix can be anything, not only physical ones, and can have each one a distinct rate (and format, as seen above). On this regard, our Haiku system audio mixer must adapt the same constraints than PulseAudio one for instance.
But it's not because the default Haiku Media nodes are setup like they are that it means the Media Kit can only support such "default" setup.
Re: Professional Sound API
I just want to pipe up and say that I really appreciate this discussion. I've been waiting for Haiku to be stable. I want to write some pro audio apps for it. I want to move away from Windows. However, I don't want to spend time writing pro audio software for Linux. I am a sound engineer. So the concerns of realtime audio are very real for me. I hope that some Haiku devs understand this, and allow for an alternate "media-kit"(JACK) to be used.
Only once this has gotten through the heads of the Haiku devs will I even begin to contemplate writing code. Without the backing of the Haiku devs, it's a waste of time to try an implement.
Is there anywhere this can be discussed in with other potential audio devs? Do we bring it to the mailing lists? Or are we all here?
All the reverse engineering that has gone into ALSA pro sound device drivers will make writing drivers for Haiku easier. I would like to have a JACK with an "FFADO" driver up and running.
For everyone that says 0.001 (or whatever it is) seconds is not audible, please talk to the hand. Maybe you cannot hear it but sound engineers can. Delays in sound will cause phasing. Saying that such and such is an acceptable amount of latency, when it could be reduced, is unforgivable from a sound engineer point of view. The best is required - not the acceptable.
Re: Professional Sound API
Is there anywhere this can be discussed in with other potential audio devs? Do we bring it to the mailing lists? Or are we all here?
You may want to bring back to life the Media Kit mailing list:
http://www.freelists.org/list/openbeosmediakit
Good luck!
Re: Professional Sound API
Only once this has gotten through the heads of the Haiku devs will I even begin to contemplate writing code. Without the backing of the Haiku devs, it's a waste of time to try an implement.
Why waiting? You're waiting JACK to be ported to Haiku before writing JACK software?
Why not writting JACK software directly on the best platform on which JACK is already ported?
Meanwhile, instead of waiting for JACK being ported to Haiku, why just not write (or adapt!) some "pro sound" benchmark software using Media Kit to help Haiku devs to identify the flaws in its design (or builtin nodes) which don't match pro sound API requirment. Because, so far, everybody seems to assume Media Kit is not up to the task without having even tried to check it, investigated why and suggested some fixes. These tools will be far more welcomed by Haiku devs than saying you wont help them making Media Kit better but you want to convince them to forgot it all and port JACK instead.
Such tools will be very usefull:
- it would bring light on the Media Kit design (or its implementation) flaws that should be fixed or improved
- it would give some momentum to port JACK sooner than later in order to offer an alternative until Media Kit becomes up to do the same, (if ever).
As a sound engineer, you're more skilled to write, run and analyze such benchmarks than us. If the Media Kit is proved to not be as ready for Professional requirments as JACK seems to be, the most obvious reason will be that the Media Kit developers count no professional sound engineer yet. We needs the skills of a pro sound guy. The Media Kit may needs your help.
To paraphrase a well known guy, don't ask Haiku what it can do for you, ask you what you can do for Haiku.
It's a open source project.
Join us.
Please. :-)
Re: Professional Sound API
You seem to be confusing 2 different elements.Mind you real time audio is a myth. If you want real time audio, play accoustic instruments. Now back to being realistic.
Latency correction or synchronization of latecy on all audio tracks in a DAW.IE sum rendering error differences are not tolerable against time code.
thats fine. but so say you have to have real time audio ? Thats bunk. You have DSP process cycle wiat times and execution regardless of how low the latency is and they just can't be gotten around regardless of how good the system is Os aside, the hardware has to crunch the math and this is impossiable to avoid, even protools DSP cards are "low Latency" but they have tons of DSP chips to run each track into its own DSP channel but it still has to have a back end synchornization time stamp at assebmly time for rendering at the master bus.
the only flaw the media kit might have is a LACK " I haven't confirmed this" of a way to keep things sycnd to the master time clock. A problem that is very easily resolved at the track level. But as you add DSP effects, reamping, external busing, bus round trips, outboard processing gear you are going to incur latency the more layers of processing you add the worse this becomes.
what we need is a way to calibrate the latency and have the DAW stick everything to one timestamp. Presonus studio one has this feature. the Kristal audio engine has this feature, Cubase has this feature and its not in the audio drive.
Jack solve none of these issues unless it is generating synchornization time code stamps for each audio stream. Which it might. Jack is a fancy software mixer. Nothing more. honestly I wouldn't consider jack pro audio level. Midas sounds boards are Pro gear. Jack is at best high end hobby software for live performance/home recording "which is whatever that is"
There is no such thing as real time audio. Get used to saying it. Its just what it is.
If you want to have a rational discussion about time code based stream synchronization and how to best implement those capabilitys into the Media kit or make a media kit API. Great. Welcome the suggestions. but stop with the latecny argument. Its really pretty tired.
Re: Professional Sound API
Well, i'm not a developer but "just" an audio producer: it would be great to have a method that manages 3rd-party effects plugins as Haiku manages video codecs backend... that's why i suggested the N.A.S.PRO. adoption !
Talking about DAW, it would be great to start upgrading HyperStudio (or, why not, Clockwerk too) by "grabbing" features from others open source DAWs (such as Ardour, Traverso, Qtractor, Rosegarden, DarkWave Studio, Koblo, etc.)
BTW i believe that the 1st correct step should be let Haiku manage professional multichannel (8+) soundcards/mixers, in order to record multiple audio streams (harddisk recording, at least).
Re: Professional Sound API
Not true. The audio physical input and output are handled by MultiAudio node, which support any audio format (8/16/32 bits integer or float) that the below kernel hardware drivers supports. If they don't support float in hardware, someone must convert it somewhere in the pipeline. It's true for JACK sources and sinks too. The difference is that the Media Kit don't enforced a format and the system audio nodes supports all formats to be able to accommodate any situation.
OK, this is the Right Thing™ in so much as it means you can do the whole pipeline in float. I have not seen this done, in BeOS or Haiku but I believe you (as the Media Kit expert) when you say that this works.
First, it's the default system mixer, but nothing forbid a pro audio solution to shortcut it totally.
It's just a matter of routing choice to make. Desktop multimedia apps routes their audio toward the system mixer because it make sense, but nothing forbid to route it toward a dedicated sink node instead. If one would want to mimic the JACK pipeline with the Media Kit, he would have to do that in fact, as JACK don't enforce either a system wide mixer client, AFAICT.
In BeOS at least, this simply doesn't work. I was not able to remove the system mixer from graphs without serious problems. This was clearly not something Be's engineers spent time on. Remember the B_SYSTEM_MIXER is not just another node on the graph as a mixer would be in JACK.
Perhaps Haiku is different. Perhaps you've actually tried it?
In the end, keep in mind that the Media Kit has to be far more flexible that JACK, who knows it's only audio 32bits samples, while the Media Kit has to support variable audio *and* video formats. Being flexible doesn't mean that it's not up for some very specialized task, it means it need far more setup and tuning to be able to it. Aka being specialized.
I'm not saying Media Kit is able to do everything JACK succeed to for audio, being the well-optimized for audio real time processing JACK is.
What I'm saying is that Media Kit was not designed to support only the playback usual case, which you seems to assert. In fact, if it was the case, it would be an overly flexible layer to accomplish just that. This flexibility is there for a reason: to adapt to more than one well-known case.
As an aside, people have transported other things over JACK. Notably MIDI and video. But you are correct that JACK's core purpose was from the outset and remains PCM audio.
On the subject of what is supported, I think there's a tendency to believe that Be did all this design work for you. You should not underestimate how much of Be's work was unfinished. There's a thread somewhere on this forum asking about Monitoring. That ought to have been covered by Be, right? But I can't even find mention of it as an "upcoming" feature like the video codec APIs.
Re: Professional Sound API
Mind you real time audio is a myth.
You seem to have misconstrued what "real time" means. A real time system has a fixed deadline. Often it is acceptable for something to occur "as soon as possible" or even just "eventually". But in real time systems, including real time audio, there is a hard deadline. The nature of the deadline varies by application.
Sound travels about 34cm per millisecond through air. By programming our software to meet a deadline such that total system latency is below 10ms, we can ensure that the effect is no different than if the listener was sat 3.4m further from the sound (e.g. speakers).
If you want real time audio, play accoustic instruments.
Acoustic instruments incur latency too. Consider a piano (a real one, say a Bösendorfer concert grand if it helps you to imagine it). After the pianist presses a key, there is a very real delay before sound comes out of the piano. The hammer strikes the strings, which then resonate, and the resonating vibration travels to the sound board and this vibrates the air causing a sound. Pianists learn to compensate.
Re: Professional Sound API
You seem to have misconstrued what "real time" means. A real time system has a fixed deadline. Often it is acceptable for something to occur "as soon as possible" or even just "eventually". But in real time systems, including real time audio, there is a hard deadline. The nature of the deadline varies by application.
Realtime audio means real time audio. Not audio 30 seconds later. It means audio from source to output now. Instantly. Thats called slick marketing and its always been BS.
Secondly, bus round trips are going to be longer then 10msec period.
consider this. Presonus make the firepod. It uses firewire. round trip bus time is 11msec regardless of the system in use. Thats not going away. they do have onboard monitoring which reduces loop time to a few msec 3-4 IIRC. but I am talking about the communication and message time from the audio interface input to the pc and back.
So we have already incurred latency on a round trip.This only really matters if your going to record a track from your instrument through the pc and monitor back out of the pc using effects software like amplitube. If your recording from a external source with no feedback monitoring like recording with a softeffects chain then its a non issue. If the DAW knows what the input latency is it can automatically correct the track offest to properly place the audio recording in the track channel off the master timestamp.
See non issue.
There is no hard deadline. There is input to output time.That will vary depending on DSP loads. Protools did all of this on there flagship system DSP cards becuase they knew that you will incure buss time penaltys with effects.
Sound travels about 34cm per millisecond through air. By programming our software to meet a deadline such that total system latency is below 10ms, we can ensure that the effect is no different than if the listener was sat 3.4m further from the sound (e.g. speakers).
try that at 500 feet below sea level and 5000 feet above. The speed of sound varies by altitude and air density and air composition. Secondly, who cares. You are not ever going to get system latency below 10msecs unless you are piping only audio streams with no processing. something that simply won't happen with softeffects chains.
Also your audience doesn't know. The issue is timestamp synchrmnization on a per track bassis.IE making sure all tracsk are aligned in time corretly. Total system latency "provided its not seconds" is essentially irrelevant. Especially at the mixing and mastering stage. The only time latecny become probleatic is if your using softeffects or instruments routed through the host machine itself and monitoring back. Hence why guys who have experience tend not to use softeffects if they are recording and monitoring back through the system.
thats not say that latency should be let to accumulate rampantly. alot of people record with softeffects so optimizations should be made to reduce these wiat times.
Acoustic instruments incur latency too. Consider a piano (a real one, say a Bösendorfer concert grand if it helps you to imagine it). After the pianist presses a key, there is a very real delay before sound comes out of the piano. The hammer strikes the strings, which then resonate, and the resonating vibration travels to the sound board and this vibrates the air causing a sound. Pianists learn to compensate.
Yes having been a professional musician I am aware of this. Thats why in orchestras we all synchronize to the conductors wand.
Re: Professional Sound API
In BeOS at least, this simply doesn't work. I was not able to remove the system mixer from graphs without serious problems. This was clearly not something Be's engineers spent time on. Remember the B_SYSTEM_MIXER is not just another node on the graph as a mixer would be in JACK.
You can't remove this mixer, because it's your sound-chip !
This hardware-embedded mixer's latency can be neglected.
edit :
Thats why in orchestras we all synchronize to the conductors Hand.
It's not enough to prevent huge latencies ! (at least in my orchestra)
;-p
Re: Professional Sound API
In BeOS at least, this simply doesn't work. I was not able to remove the system mixer from graphs without serious problems. This was clearly not something Be's engineers spent time on. Remember the B_SYSTEM_MIXER is not just another node on the graph as a mixer would be in JACK.
You can't remove this mixer, because it's your sound-chip !
This hardware-embedded mixer's latency can be neglected.
edit :
Thats why in orchestras we all synchronize to the conductors Hand.
It's not enough to prevent huge latencies ! (at least in my orchestra)
;-p
I should assume you are running a softorchestra in a vst ? the fact of the matter is. There is only so much the Os can do. at some point it boils down to hardware capability "even though OS guys don't wanna hear that" to get the work done.
One of the methods I have gone to is uing more comprehensive midi routing to instruments. IE route a midi channel to each innstrument in a VST. some VST do not support this and a few do.
again though the key issue is not latency per say but synchronization of all the tracks relative to a master time code. IE if we start to dispatch threads to various VST components they must all align back to the same time stamp. Mostly on windows DAW's this is all done by the DAW itself.
again I think there is some badly stated thoery of operation here. the only time latency issue become prevelant is track instrument monitoring with softeffects. Aside from that. Loop back times are hardware constrained. There is at least a 3ms input and output delay on the audio card itself not to mention bus delays etc.
This is a are where gpu acceleration would prove beneficial though.handing off DSP functions to the GPU is what those devices where made for. Getting integration into Haiku at the moment would be challenging.
My advice. get a good source sound and focus on the mix.
Re: Professional Sound API
You can't remove this mixer, because it's your sound-chip !
This hardware-embedded mixer's latency can be neglected.
B_SYSTEM_MIXER is the BeOS (or now Haiku) system mixer, if you encounter it at all as a non-programmer, it will be in the form of per-application "volume knobs" in Haiku.
It is a piece of software, written for Haiku, as part of the Media Kit.
Re: Professional Sound API
Realtime audio means real time audio. Not audio 30 seconds later. It means audio from source to output now. Instantly. Thats called slick marketing and its always been BS.
I have explained what real time audio is. It does you no good to make up a new meaning for an established term.
Secondly, bus round trips are going to be longer then 10msec period.
Is this the same mistake you made earlier, confusing a millisecond and a microsecond? On a fairly ordinary PC running JACK we can set the sample frequency to 48kHz (a good choice for non-crazy people who aren't making CDs), set the period length to 128 frames, and then what will happen is this:
2.66.. milliseconds of audio is recorded into a buffer via an ADC, which adds a few microseconds of latency of its own which we will disregard. An interrupt is fired (meanwhile the next 2.66.. milliseconds of audio continues to be collected). JACK converts the integer PCM data to float, wakes up the first node in its graph, which processes the data and it is passed to the next node, and so on, perhaps through a dozen nodes, then the output is converted back to integer, and written to the output buffers on the sound chip, all during the 2.66.. milliseconds before the next interrupt fires. There is again a set of filters on the output DAC which incurs some microseconds of additional latency when the PCM data is played back in that next period.
So overall the time from sound reaching a microphone or equivalent to being fed into an amplifier after running through the JACK audio chain, will be about 5-6 milliseconds with this setup. People use systems like this every day. On some cheap PC cards the interrupt is routinely "late", requiring an extra buffer period for a total round trip of no more than 8-9 milliseconds.
consider this. Presonus make the firepod. It uses firewire. round trip bus time is 11msec regardless of the system in use. Thats not going away.
I have no idea where you got this figure from. Although firewire incurs some extra latency, I have heard of people running such devices with 32 frame periods on OS X, I'm sure the 128 frame latency example I gave above would also work fine over firewire.
There is no hard deadline. There is input to output time.That will vary depending on DSP loads. Protools did all of this on there flagship system DSP cards becuase they knew that you will incure buss time penaltys with effects.
The Protools system is indeed working to a hard deadline. Much like I described for JACK above, although the exact mechanics are very different in Protools.
Re: Professional Sound API
Realtime audio means real time audio. Not audio 30 seconds later. It means audio from source to output now. Instantly. Thats called slick marketing and its always been BS.
I have explained what real time audio is. It does you no good to make up a new meaning for an established term.
Secondly, bus round trips are going to be longer then 10msec period.
Is this the same mistake you made earlier, confusing a millisecond and a microsecond? On a fairly ordinary PC running JACK we can set the sample frequency to 48kHz (a good choice for non-crazy people who aren't making CDs), set the period length to 128 frames, and then what will happen is this:
2.66.. milliseconds of audio is recorded into a buffer via an ADC, which adds a few microseconds of latency of its own which we will disregard. An interrupt is fired (meanwhile the next 2.66.. milliseconds of audio continues to be collected). JACK converts the integer PCM data to float, wakes up the first node in its graph, which processes the data and it is passed to the next node, and so on, perhaps through a dozen nodes, then the output is converted back to integer, and written to the output buffers on the sound chip, all during the 2.66.. milliseconds before the next interrupt fires. There is again a set of filters on the output DAC which incurs some microseconds of additional latency when the PCM data is played back in that next period.
So overall the time from sound reaching a microphone or equivalent to being fed into an amplifier after running through the JACK audio chain, will be about 5-6 milliseconds with this setup. People use systems like this every day. On some cheap PC cards the interrupt is routinely "late", requiring an extra buffer period for a total round trip of no more than 8-9 milliseconds.
consider this. Presonus make the firepod. It uses firewire. round trip bus time is 11msec regardless of the system in use. Thats not going away.
I have no idea where you got this figure from. Although firewire incurs some extra latency, I have heard of people running such devices with 32 frame periods on OS X, I'm sure the 128 frame latency example I gave above would also work fine over firewire.
There is no hard deadline. There is input to output time.That will vary depending on DSP loads. Protools did all of this on there flagship system DSP cards becuase they knew that you will incure buss time penaltys with effects.
The Protools system is indeed working to a hard deadline. Much like I described for JACK above, although the exact mechanics are very different in Protools.
So what exactly is your point ? you just got owned, by someone with obvious experience and you just can't accept defeat.
I did some looking on my own and if you want to now base latency on samples typical buffers even in high end systems run nearly 500 frames to achieve stability regardless of the Operating system in use.
you argument ring hollow and is not widely supported by evidence of industry wide research to the exact opposite.
I see you again making negative posts against haiku.
If you don't like haiku, hit the logout button and don't let the door hit you on the ass on the way out.
do you even understand what timestamp code is used for ? the author you qouted is correct. there is no such thing as real time audio processing. Its a marketing buzzword.
Re: Professional Sound API
So what exactly is your point ? you just got owned, by someone with obvious experience and you just can't accept defeat.
After you accidentally burn a sock account:
12msec is 0.00012 seconds
Yeah I misplaced the decimal and its still faster then you blink.
... it's not a good idea to use that sock in the very same thread to prop yourself up.
Re: Professional Sound API
Why are you still here???, go back to linux land. Nevermind the fact that you have absolutely no idea WTF you are talking about.
Re: Professional Sound API
If you have interess, could help to port OpenAL for Haiku
http://ports.haiku-files.org/ticket/366
Re: Professional Sound API
If you have interess, could help to port OpenAL for Haiku
http://ports.haiku-files.org/ticket/366
I'd rather not port anything but fix the media server backend. I don't even know if its broke. Most of this "strawman issue" is handled at the daw itself in regards to latency compensation.
When I get a bit more up to speed on c and c++ I'll see what I can offer. But honestly it would be better to integrate the openAl features into the mediakit API versus adding yet another layer of abstraction to slow down the system, ergo making latency worse.