Professional Sound API

Feedback Ideas
61

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.[/quote]

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.

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.

62

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.

63

You may want to bring back to life the Media Kit mailing list:

http://www.freelists.org/list/openbeosmediakit

Good luck!

64

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. :slight_smile:

65

[quote=NoHaikuForMe]
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. [/quote]

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.

[quote=NoHaikuForMe]
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).[/quote]

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.

[quote=NoHaikuForMe]
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. [/quote]

Yes having been a professional musician I am aware of this. Thats why in orchestras we all synchronize to the conductors wand.

66

You can’t remove this mixer, because it’s your sound-chip !
This hardware-embedded mixer’s latency can be neglected.
edit :

It’s not enough to prevent huge latencies ! (at least in my orchestra)
;-p

67

You can’t remove this mixer, because it’s your sound-chip !
This hardware-embedded mixer’s latency can be neglected.
edit :

It’s not enough to prevent huge latencies ! (at least in my orchestra)
;-p[/quote]

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.

68

[quote=starsseed]You can’t remove this mixer, because it’s your sound-chip !
This hardware-embedded mixer’s latency can be neglected.[/quote]

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.

69

[quote=thatguy]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.
[/quote]

I have explained what real time audio is. It does you no good to make up a new meaning for an established term.

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.

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.

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.

70

[quote=NoHaikuForMe][quote=thatguy]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.
[/quote]

I have explained what real time audio is. It does you no good to make up a new meaning for an established term.

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.

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.

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.[/quote]

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.

71

After you accidentally burn a sock account:

… it’s not a good idea to use that sock in the very same thread to prop yourself up.

72

Why are you still here???, go back to linux land. Nevermind the fact that you have absolutely no idea WTF you are talking about.

73

If you have interess, could help to port OpenAL for Haiku

http://ports.haiku-files.org/ticket/366

74

[quote=michaelvoliveira]If you have interess, could help to port OpenAL for Haiku

http://ports.haiku-files.org/ticket/366[/quote]

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.