Jack Audio experiences?

[kmatheussen]

You are all over the place with your arguments. First you say it's a problem that jack does NOT synchronize audio with MIDI

That's an outright lie - I never said that.

Well, it's hard to interpret "JACK's big problem with MIDI is that it is not in sync with audio -- it runs to a separate clock" any other way, although I guess maybe you meant to write "JACK's big problem with MIDI is that MIDI is not in sync with audio -- it runs to a separate clock", but that's not what you wrote.

I said that it's not desirable to have Audio and MIDI synchronised. What is desirable is to pass data around without delay. This JACK achieves for Audio. Last I looked, the MIDI system did not achieve this.

The only reason the JACK team had accepted that implementation was it was the only one on offer and they wanted some MIDI coverage. I think the argument ran "Well, if no one else cares enough to get it right, we might as well just do it this way."

I have no idea what you are talking about here, the only thing I see are accusations. Do you have any link that explains more about why you believe jack is "broken by design"?

[Dewdman42]

Don't use WineBottler. Use Wine.App from their site. From their downloads page its further down the page. Its a much simpler Wine implementation then the actual bottler.

Once you have that, copy the wineasio.dll.so to the path I mentioned before. and then run the regsvr32 command. Actually I just noticed the path I mentioned wasn't quite right. It should be this:

Code: Select all

/Applications/Wine.app/Contents/Resources/lib/wine/wineasio.dll.so

I tried this, but sadly it is not working

Thanks anyway for the help.

Would be nice if they bundled this with future Wine releases.

Send me a PM and I can help you get it working. It's not that difficult there must be some small thing.

Unfortunately wineasio will probably never get bundled with wine because it requires asio.h header file from Steinberg and mostly wine is distributed as source, not as a pre compiled package. Asio.h cannot be distributed. So wineasio is unlikely to be included in wine. It's been around for a long time and used a lot more on Linux. The OS X port of wineasio has a few significant changes compared to the Linux version so the Linux wineasio folks don't want to know about it. The guy who did the OS X port of wineasio is supposedly trying to find a way to merge it into the wine distribution but even if he gets it all working he will still be faced with the asio.h src distribution problem. Don't hold your breathe waiting. It's been about five years since the current OS X port of wineasio was written.

I am also trying to get the wine bottler author to consider bundling it in to that OS X specific port of wine. But it's difficult to get non audio people to even understand what asio is or why it needs to be included in the wine distro. I already looked into the possibility of adding it to winetricks but it's not possible because winetricks only installs pure Windows stuff and wineasio is a wine thing. Technical issue. The best prospect would be to get some of the more popular OS X wine distributions to include options to install wineasio automatically. So ask them! Wine bottler, wine skin, osxwinebuilder, there may be others. They each bundle up wine in a slightly different way so it's difficult to write a wineasio installer that can address them all.

The easiest way to use wineasio right now is to just manually install it. PM me if you'd like to get it working. It's actually easy once you do it a few times.

Last night I did some tests between Logic Pro and Cantabile2 using it. I had consistently less then 2ms round trip latency of sending midi from a logic pro midi track over IAC to cantabile on wine, vst instrument on cantabile produced sound and sent the audio back to logic over jack with 256 buffer size to record the audio to a track in logic. The audio was 2ms behind the midi events back in logic. Use a negative delay on the logic midi track of -2ms and its spot on. Totally usable!

[pljones]

Well, it's hard to interpret "JACK's big problem with MIDI is that it is not in sync with audio -- it runs to a separate clock" any other way, although I guess maybe you meant to write "JACK's big problem with MIDI is that MIDI is not in sync with audio -- it runs to a separate clock", but that's not what you wrote.

You found two meanings pretty easily and, despite my prior posts in this thread, chose to take a meaning that fed you to lie about me. There are several nouns in that sentence, two of them closer to the pronoun "it" than the one you chose to assign.

[kmatheussen]

Well, it's hard to interpret "JACK's big problem with MIDI is that it is not in sync with audio -- it runs to a separate clock" any other way, although I guess maybe you meant to write "JACK's big problem with MIDI is that MIDI is not in sync with audio -- it runs to a separate clock", but that's not what you wrote.

You found two meanings pretty easily and, despite my prior posts in this thread, chose to take a meaning that fed you to lie about me. There are several nouns in that sentence, two of them closer to the pronoun "it" than the one you chose to assign.

1. You talked about MIDI for Jack, and referred to something as "it". It doesn't
make sense that this "it" should be MIDI or Jack. 2. Even if a person should
interpret your "it" to refer to MIDI, it wouldn't make sense since you talk
about different clocks between MIDI and Audio as a very special thing that
only Jack would have problems with. So the brain would naturally parse out that
interpretation if there had been any doubt what it would refer to.

[nbd]

I think the dilemma is that if MIDI is synced with audio then any MIDI source (like human playing MIDI keyboard) that produces events during the actual processing of the audio buffer there is no easy way to achieve near-zero latency for MIDI events. The MIDI events will be delayed by the current latency, but it could be very little with modern systems.

Where MIDI-audio sync works the best is when all midi data is already there on it's own place and just need to be fed to softsynths to produce the sound (like when bouncing a project), and this is where the sync really matters, since you don't want to have different results per every bounce. This is where Jack-MIDI shines.

And for Live performance I would choose the way where MIDI is processed as fast as possible.

[Dewdman42]

Yep definitely and that is the case even for when you are just working in your daw without jack at all. Live midi playing will always be subjected to some midi jitter because of the way midi device drivers work, IN ADDITION, to the audio latency for hearing it, which is consistent but still latent.

While playing back a midi track without jack, the daw renders the midi data into audio and plays it perfectly sample accurate in sync with the audio, again, latant but perfectly in sync no jitter. But if the midi track is playing back an external keyboard, then the midi timing jitters around a bit on the midi cable, but not bad because of time stamping; the external instrument produces sound which has to come into the sound card and will experience some more latency before reaching the daw, etc. not sample accurate.

Basically for live playing, sample accuracy is irrelevant. For rendering midi tracks it would be prerable when possible to have it.

Slightly unrelated,

In case anyone is interested I did some testing with using jack to send audio in an fx loop from one recorded track to another program and back again to loop back the audio to a second track. Then I inspected the two tracks to see how much latency there was on the second track. Oddly, the looped back track was EARLY not late. On DP it was early by exactly the same amount as my audio buffer, 256 samples. In my mind this means somehow jack is getting the audio data around with out introducing any extra latency and it's one buffer too early bringing it back to the program but would be perfectly in sync if it were headed to a sound card. I did the same test with Logic and logic was consistently early getting it back by BUFFER*2+150; no matter what buffer size I used.

When sending a midi track over IAC to another program and returning the audio through jack to record it, I do not get this early audio. Actually even stranger; on logic I tried it two ways. I did it once with an external instrument track using the external inst plugin, which itself sends the midi and receives the audio from audio input port. And I did it once without that external inst plugin, the track itself sends the midi through logic and the audio comes back through an input to a sellers the audio track. The first way with the plugin the audio is within 2ms of the midi event, even when bussing to another audio track to record it. It's subject to some IAC jitter but within a ms I guess. Not sample accurate but very useful. The second way without the ext inst plugin it's also subject to IAC jitter but the audio comes into logic early again. I didn't measure how early yet.

What I can deduce is that DP and logic are sending audio to jack one buffer early in anticipation that it will take one buffer before the sound card will produce it, but when it just goes to another program and back again to this program; the latency is never produced so it ends up arriving back early. As to why logic is even earlier then that, I do not know. Double buffer plus 150. But it doesn't happen when using the external inst plugin. I'd be willing to bet that if jack-insert was working on 64bit it would also not have any latency or earliness for a test like this. Something about the output ports in logic/DP is sending stuff ahead of schedule to jack. Logic is doing it by a lot. Just my guess. But I still don't know why the install track rendering through an input port also makes it early. Well something is definitely amis there. You can deal with it by temporarily setting the record delay preference, then the incoming will be exactly on time. But it's a bit of a hack. I'd like to find a plugin that can send and receive directly to core audio ports itself, perhaps bypassing this problem. The good news about all of this is that jack is not adding latency. The DAW's are trying to compensate for audio card latency and confusing the issue when no sound card is present in the path

[Dewdman42]

If your head isn't ready to explode after reading that, then try doing some tests yourself and it will be.

Anyway, bottom line is that when jack is used through core audio, as it currently is in JackOSX, then its not sample accurate anyway. If the program were using dedicated calls to the Jack API on both ends (in both programs), then maybe it would be and in that case it would be very useful for jack midi to ensure the midi tracks are also sample accurate, when you're playing back midi tracks...just like happens now when you do it all inside of one DAW. For live midi it would be irrelevant and advantageous for the midi to always be sent across as soon as possible (with midi timestamps attached to midi events of course), attempting to get the receiving app to always receive the midi and render it as soon as possible after you play it on the keyboard.

But when JackOSX is usually in most cases using core audio input/output ports to connect with various programs that are ignorant about jack themselves, then those programs may opt to do various trickery of their own, as they believe they are sending and receiving audio to a sound card, rather then the jack system. When they do that trickery...sample accuracy is lost.

In the case of Logic anyway, the external instrument plugin and the utility I/O plugin can be used to resolve these issues and get it working very well though.

[marioisaac]

Don't use WineBottler. Use Wine.App from their site. From their downloads page its further down the page. Its a much simpler Wine implementation then the actual bottler.

Once you have that, copy the wineasio.dll.so to the path I mentioned before. and then run the regsvr32 command. Actually I just noticed the path I mentioned wasn't quite right. It should be this:

Code: Select all

/Applications/Wine.app/Contents/Resources/lib/wine/wineasio.dll.so

I tried this, but sadly it is not working

Thanks anyway for the help.

Would be nice if they bundled this with future Wine releases.

Send me a PM and I can help you get it working. It's not that difficult there must be some small thing.

Unfortunately wineasio will probably never get bundled with wine because it requires asio.h header file from Steinberg and mostly wine is distributed as source, not as a pre compiled package. Asio.h cannot be distributed. So wineasio is unlikely to be included in wine. It's been around for a long time and used a lot more on Linux. The OS X port of wineasio has a few significant changes compared to the Linux version so the Linux wineasio folks don't want to know about it. The guy who did the OS X port of wineasio is supposedly trying to find a way to merge it into the wine distribution but even if he gets it all working he will still be faced with the asio.h src distribution problem. Don't hold your breathe waiting. It's been about five years since the current OS X port of wineasio was written.

I am also trying to get the wine bottler author to consider bundling it in to that OS X specific port of wine. But it's difficult to get non audio people to even understand what asio is or why it needs to be included in the wine distro. I already looked into the possibility of adding it to winetricks but it's not possible because winetricks only installs pure Windows stuff and wineasio is a wine thing. Technical issue. The best prospect would be to get some of the more popular OS X wine distributions to include options to install wineasio automatically. So ask them! Wine bottler, wine skin, osxwinebuilder, there may be others. They each bundle up wine in a slightly different way so it's difficult to write a wineasio installer that can address them all.

The easiest way to use wineasio right now is to just manually install it. PM me if you'd like to get it working. It's actually easy once you do it a few times.

Last night I did some tests between Logic Pro and Cantabile2 using it. I had consistently less then 2ms round trip latency of sending midi from a logic pro midi track over IAC to cantabile on wine, vst instrument on cantabile produced sound and sent the audio back to logic over jack with 256 buffer size to record the audio to a track in logic. The audio was 2ms behind the midi events back in logic. Use a negative delay on the logic midi track of -2ms and its spot on. Totally usable!

2 ms delay!!! I just PM'd you!