Jack Audio experiences?

[pljones]

JACK's big problem with MIDI is that it is not in sync with audio -- it runs to a separate clock. It also supports bulk data messages (i.e. large SysEx messages) which JACK cannot handle. Thus using JACK for MIDI can badly break a lot of things and introduces jitter and latency in the MIDI path.

[nbd]

JACK's big problem with MIDI is that it is not in sync with audio -- it runs to a separate clock. It also supports bulk data messages (i.e. large SysEx messages) which JACK cannot handle. Thus using JACK for MIDI can badly break a lot of things and introduces jitter and latency in the MIDI path.

This is not actually JACK's fault. It's because most of the programs that use JACK for audio, does not use JACK-midi API. I'm not sure how JackOSX or the Windows version handles midi, but I doubt that they use MIDI any better unless they really are built using the JACK-midi callbacks.

I have the feeling that there are too many programs that have added JACK audio as an extra audio output option, instead of really building the thing from the ground up. And the fact that MIDI support for JACK came along much later than the audio part and the JACK MIDI framework is hugely different from what the ALSA MIDI was. (I'm not sure how CoreMIDI is done, or how things are in the Windows world with its always changing audio API's)

I have looked into some open source midi software (Linux) and found out that the needed changes for proper JACK-midi support would mean a total rewrite.

I found out that the fundamental difference is (in layman terms) that JACK-midi processes the midi events just like the audio buffers; it provides a certain amount of audio (depends on the buffer size and number of buffers) that is needed for the next buffer to be sent out (to audio card or whatever it is routed to). So let's say it's 50 milliseconds. At the same time for midi, it would read the next 50 milliseconds of forthcoming midi events and process those. All those midi events are perfectly synced to the audio samples every time.

To my understanding in ALSA midi, there is no synchronization like this. It is not synced to the audio samples, so there will be a drift between ALSA midi and audio.

[Dewdman42]

This is more or less how I understand it. If a program has specific jack midi support coded into it, then you can have perfect audio midi sync. If not then they are totally separate. There are almost no programs on the mac that have anything related to jack audio or midi coded into them. In the case of audio, core audio delivers sample accurate audio. If it didn't everything you hear would sound like crap. So it's quite easy for a program to just use the jackosx core audio driver and treat it like an audio device without knowing anything more about it. Core midi, however, does not have anything in it to synchronize midi with audio. It has midi time stamping of its own, and IAC works reasonably well, but there is no garauntee of sample accurate sync with some other audio stream. Plus jackOSX does not present the midi part of itself as a system wide coremidi midi device like it does for audio.

In order for two Mac programs to use jack midi in sync with audio, they both have to directly use the jack api rather then relying on the jack audio device driver. Then they would theoretically have performance similar to rewire. Jackosx does provide midi support but I don't know of any programs using it yet.

That being said, I have used IAC midi together with jack audio to communicate between two Mac audio apps and it works reasonably well. You get a few ms delay on the midi is all.

I also routinely use Windows audio apps and plugins on my Mac with wine and there is a little driver called wineasio that basically makes the Windows program think it's talking to an asio driver but really talks to the Mac jackosx system. And wine can already see IAC midi. So yea I am a able to use win32 apps and plugins on my Mac and they can be bussed through Logic Pro.....all using jackosx and IAC

[marioisaac]

I also routinely use Windows audio apps and plugins on my Mac with wine and there is a little driver called wineasio that basically makes the Windows program think it's talking to an asio driver but really talks to the Mac jackosx system. And wine can already see IAC midi. So yea I am a able to use win32 apps and plugins on my Mac and they can be bussed through Logic Pro.....all using jackosx and IAC

Have you solve audio latency with wineasio?
I tried using Windows Audio Apps with Wine on a MAc, and latency was about 200 ms.
How much latency do you get?

Can you use VST's with WINE? How would you do that? Copy Dll's into VST Folder?

[pljones]

I found out that the fundamental difference is (in layman terms) that JACK-midi processes the midi events just like the audio buffers; it provides a certain amount of audio (depends on the buffer size and number of buffers) that is needed for the next buffer to be sent out (to audio card or whatever it is routed to). So let's say it's 50 milliseconds. At the same time for midi, it would read the next 50 milliseconds of forthcoming midi events and process those. All those midi events are perfectly synced to the audio samples every time.

This is exactly the problem. It introduces jitter and latency into the MIDI path that need not be there. The API simply does not support bulk SysEx (or didn't last time I looked), which means you can't simply wrap it over a MIDI interface and have everything continue to just work.

[Dewdman42]

I also routinely use Windows audio apps and plugins on my Mac with wine and there is a little driver called wineasio that basically makes the Windows program think it's talking to an asio driver but really talks to the Mac jackosx system. And wine can already see IAC midi. So yea I am a able to use win32 apps and plugins on my Mac and they can be bussed through Logic Pro.....all using jackosx and IAC

Have you solve audio latency with wineasio?
I tried using Windows Audio Apps with Wine on a MAc, and latency was about 200 ms.
How much latency do you get?

Can you use VST's with WINE? How would you do that? Copy Dll's into VST Folder?

Yes wineasio has solved the latency problem a long time ago, but its hard to find information about how to do it. Latency is tiny...its completely useable when setup right. I don't know what it is for me, I don't have a way to measure, but I can't hear any latency. I believe it must be the same latency as mac apps would have using jack to share audio between them.

You just use some vst host app, such as VstHost.exe, Reaper.exe or many others that I have found to work fine in wine. Then put your VST dll's whereever you want and tell the app where they are and it runs just like its on windows.

If you're on OSX get the latest version of wineasio here:

https://github.com/steveschow/osxwineasio/releases

Get Wine.app from here: http://winebottler.kronenberg.org/downloads

Copy the wineasio.dll.so inside the Wine.app bundle here:

Code: Select all

/Applications/Wine.app/Contents/Resources/lib/

Run the wine command line and execute the following line:

Code: Select all

regsvr32 wineasio.dll

it should say "DLL registered successfully". Then you're good to go. Install your favorite VST host into wine, I recommend you start with VstHost.exe because I know it works and its free. But many others work great also like Reaper, EnergyXT. if you know anything about wine, sometimes you have to install some other DLL's to get a program working, so you're on your own for that, that's basic wine stuff.

Put the VST plugin DLL's you want to use wherever makes sense for you. I keep my win32 DLL's in here:

Code: Select all

~/.wine/drive_c/Program Files/VstPlugins/

The above is where wine by default will create a virtual hard drive space for wine to run apps. So when you run win32 programs they will tend to be rooted under that drive_c dir mentioned above. But you are not limited to that, you can find any OSX dir from within a wine program.

Once you have installed the VST host of your choice and some plugins, then first launch JackOSX and start it. Then launch VstHost.exe through wine. when it comes up go into preferences immediately and set the audio device to wineasio. select the midi device you plan to use for playing. Configure it to find the VST plugins mentioned above and scan them. Then load the plugin and make some sound. No latency.

If you want to use the above mentioned in conjunction with LogicPro or some other mac daw, then you probably want to create a midi IAC port to send midi from Logic to wine...and then when you launch both programs, the JackOSX router will see them and you can patch the output from wine to the input of Logic and bam...low latency playing of midi tracks in Logic through the wine based plugin. the latency is no worse then using an external synth. possibly lower then that.

[marioisaac]

Hey thanks for your insightful reply Dewdman42. Much appreciated.
If this works is super good news. I'll try it on my system.

[marioisaac]

If you're on OSX get the latest version of wineasio here:

https://github.com/steveschow/osxwineasio/releases

Get Wine.app from here: http://winebottler.kronenberg.org/downloads

Copy the wineasio.dll.so inside the Wine.app bundle here:

Code: Select all

/Applications/Wine.app/Contents/Resources/lib/

Run the wine command line and execute the following line:

Code: Select all

regsvr32 wineasio.dll

I made it here but received an error.

From Winebottler I get a WineCombo.DMG file, I opened that and on the Wine.App make a right click, show package contents and I made it to /Contents/Resources/lib/. I does not let me copy the WineAsio dll.

I then installed, go to Applications Folder, right click, show package contents, and copy the WineAsio dll in here /Applications/Wine.app/Contents/Resources/lib/.

After that I try to open Wine.App, and receive the following message: “Wine” is damaged and can’t be opened. You should move it to the Trash.

Run the wine command line and execute the following line:

How do I run the Wine Command Line.?

For the record, I am using OS X Mountain Lion.

[marioisaac]

The previous post relates to what happened with WineBottlerCombo.1.8.DMG.

Now I tried installing the stable version WineBottlerCombo.1.6.DMG.

I installed, then copied the wineasio.dll.so, in the refered path. After that I opened Wine, clicked on the upper icon, select DOS prompt, and run

C:\>regsvr32 wineasio.dll

After hitting enter, no message appeared.

Then i tried running

C:\>regsvr32 wineasio.dll.so

Did not receive any message either.

I tried to use some Windows App but ASIO is not available

[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

[kmatheussen]

JACK's big problem with MIDI is that it is not in sync with audio -- it runs to a separate clock. It also supports bulk data messages (i.e. large SysEx messages) which JACK cannot handle. Thus using JACK for MIDI can badly break a lot of things and introduces jitter and latency in the MIDI path.

That's just wrong. It's the complete opposite. JACK MIDI is perfectly synced to audio, using the same clock. That's the whole point of JACK MIDI.

[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.

[pljones]

JACK's big problem with MIDI is that it is not in sync with audio -- it runs to a separate clock. It also supports bulk data messages (i.e. large SysEx messages) which JACK cannot handle. Thus using JACK for MIDI can badly break a lot of things and introduces jitter and latency in the MIDI path.

That's just wrong. It's the complete opposite. JACK MIDI is perfectly synced to audio, using the same clock. That's the whole point of JACK MIDI.

Yes it is the whole point of JACK MIDI. And it's the whole reason JACK MIDI is broken by design: MIDI and audio do not share a clock in the real world and MIDI messages are not necessarily smaller than an audio buffer. By delaying a MIDI signal and breaking it up into chunks you are unnecessarily causing jitter and latency in the flow of MIDI messages. You also preclude normal MIDI data flows by limiting the maximum size of a MIDI data chunk. So it's simply broken.

[kmatheussen]

JACK's big problem with MIDI is that it is not in sync with audio -- it runs to a separate clock. It also supports bulk data messages (i.e. large SysEx messages) which JACK cannot handle. Thus using JACK for MIDI can badly break a lot of things and introduces jitter and latency in the MIDI path.

That's just wrong. It's the complete opposite. JACK MIDI is perfectly synced to audio, using the same clock. That's the whole point of JACK MIDI.

Yes it is the whole point of JACK MIDI. And it's the whole reason JACK MIDI is broken by design: MIDI and audio do not share a clock in the real world and MIDI messages are not necessarily smaller than an audio buffer. By delaying a MIDI signal and breaking it up into chunks you are unnecessarily causing jitter and latency in the flow of MIDI messages. You also preclude normal MIDI data flows by limiting the maximum size of a MIDI data chunk. So it's simply broken.

You are all over the place with your arguments. First you say it's a problem that jack does NOT synchronize audio with MIDI, which would have been a problem, if it was true. Now, you say that the problem IS that jack synchronizes audio with MIDI, and that this synchronization both causes latency and jitter. However, Jack neither causes latency nor jitter. It just informs you when the MIDI messages appear in the audio stream. If you ignore this information (by assuming that all messages appear at the start of each audio block), then you would get the sound out of the loudspeakers quicker, but you would also get JITTER, which is usually worse. But whatever you do, JACK doesn't force you either way. You can also read MIDI directly, and eliminate jitter by doing the synchronization manually, but it is easier to let jack do this for you automatically.

But it's not quite clear what you are talking about. If there is some special situation where you want to send around SysEx messages in realtime, you are doing something that neither Jack nor MIDI is meant to handle. In this discussion you are making the impression that jack midi is fundamentally broken, which it is most likely not.

[pljones]

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. 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."