Jack support?


#1

Hi, Im trying to get my midi/audio software working on Linux and I am having problems accessing the alsa audio drivers. As I read through the pages (!) on Linux Audio Problems I found krakens code but i cant find any “official” JUCE code in the svn trunk related to JACK. I see in the posts that Jules keeps threatening to implement Jack support and wonder what the current state of this effort is? Also, if its underway will it also include jack MIDI connections or would one still need Alsa for that?
Thansk for any infomation!
–rick
[/b]


#2

Yes, sorry, I do keep threatening to do it, but just haven’t yet found the time!


#3

With the few lines of fixes I suggested, ALSA would actually be working in JUCE - I think it would be a matter of minutes to fix the ALSA code. :smiley:
Here it works well, although I can’t go under 128 samples buffersize - there the audio drops start, but that’s ofcourse not JUCE’s fault.

For reference, see: http://www.rawmaterialsoftware.com/juceforum/viewtopic.php?t=1338&start=30


#4

+1 for the jack request… i don’t necessarily want the output of my program going directly to the speakers. =)


#5

[quote=“zamrate”]Here it works well, although I can’t go under 128 samples buffersize - there the audio drops start, but that’s ofcourse not JUCE’s fault.
[/quote]

probably you don’t use a realtime patched kernel :smiley:
1.5 ms latency here with alsa too.

i posted thousand times the code in the forum, but as usual here the improvements to linux go directly in the thrash bin.

here you go for jack support in JUCE:

http://code.google.com/p/juced/source/browse/trunk/juce/src/native/linux/juce_linux_JackAudio.cpp


#6

That sounds a bit bitter! Sorry - are you talking about me not adding jack support, or about some alsa improvement?


#7

thanks for that! i didn’t use the search, i just saw this thread first.

is it really just those 3 include lines, or is some of the other code changed as well?


#8

that was explicitly bitter ! i got tired too much helping with those features. we have browser plugins and apple remote classes but not jack audio support in juce right now… sounds ludicrous

soundcyst:

go a and check out juced code, if you are looking for jack support and other good things not in the juce tree.


#9

Putting aside this momentary glitch in the unusually mellow juce forum vibe, I would like to add that jack would be a really good thing to have. It seems that it’s become the ‘usual’ add for Linux audio systems, so other projects, for instance FFADO (firewire audio interfaces) are just working with jack, not alsa.

ALSA might well be becoming irrelevant as a stand-alone system, at least for ‘real’ audio uses.

Bruce


#10

Not to fan the flames too much, but I just wanted to voice also my perpetual dismay at JACK falling by the wayside in JUCE’s development. I understand that other platforms may be higher priorities, given concerns of commerce, but lack of JACK for such a long time really gives off a sense that either Jules is out of touch with the desires of Linux audio community or just doesn’t care. Unfortunately I’m not really prepared to develop using just kraken’s fork, since I still care about other platforms.

That said, gratitude again for the fine work to both kraken and Jules. If only you guys can manage to meet somewhere in the middle :slight_smile:


#11

Ok, I hear you all!

When you see me adding a seemingly niche feature instead of a “bigger” one like jack, it’s generally because I need it for a 3rd-party project that I’m working on - and those have tended not to involve very much linux, so that’s my excuse!

But… I’m finally becoming a little more free from some projects that have been taking up my time recently, and one thing I’d like to do is dedicate some time to tidying up the library. This seems like a good feature for me to add while I’m doing that - so I promise I’ll get on with it very soon indeed…


#12

Ok, I’ve checked in some JACK code (finally!)

Unfortunately I can’t get jack to work properly at all on my linux VM, so don’t really know if this will work…

I took the kraken’s excellent code, gave it a good sanity-checking and spring-cleaning, and it’s there in the build now. (I didn’t add the jack bridge code, mainly because I’ve no idea what it actually does…)

Would appreciate some feedback on it from people with functioning jack systems!


#13

Thanks, Jules! I’m testing this out. The only trouble I’ve had is with the Juce JACK client trying to automatically set up its connections. Input and output systems are set to ‘none’, then I switch one of them to ‘system’ (my main JACK inputs and outputs) and it will crash somewhere in the JackAudioIODevice::open() method. I commented lines 236-282 in juce_linux_JackAudio.cpp, so that Juce simply creates its own ports, and then I connect them via qjackctl (this is the way most applications work too). I also commented out the jack_port_connected checks in getActiveInputChannels() and getActiveOutputChannels(), so that it just assumes that all existing ports are valid. Calls to that were crashing, and the switching behavior seemed funny from the AudioDeviceSelectorComponent. With these changes, it seems to work nicely, and I can use my software in Linux!! :slight_smile:

So, I’m not sure about others’ preferences, but in my case I might rather have it this way, not automatically trying to connect the ports automatically. If I could simply specify the number of input and output ports I want my JUCE JACK application to create, that would be great. (If I could set individual names, it would be even better ;-P) But that would be rather different than any of the other parallel subsystems, so a lot of the wrapper code would become funny. Really, it would be ideal to save the connection settings via LASH, but that’s a whole other can of worms, and honestly I’m not sure how mature LASH is at the moment… maybe someone else can comment.

Regarding the JACK bridge (someone correct me if this is wrong): for a long time, JACK planned to support MIDI in its spec, but the implementation was left by the wayside. Consequently, people have used the ALSA sequencer for MIDI since then. It works great as a general interapplication MIDI routing system. However, recently JACK did finally implement MIDI support, and the advantage is that the MIDI routing is synced sample-accurate with the JACK audio routing. Afaik, JACK bridge is simply a convenience layer for the many many programs written using the ALSA sequencer for MIDI support to interact with programs using the newer JACK MIDI layer. Incidentally, if I build JUCE with JACK support and without ALSA support right now, there is no MIDI support (unsurprisingly)

My two cents and initial impression. I’ll of course keep playing and hacking with this. Thanks again for the great work!


#14

Thanks! My preference is for it to connect itself automatically, though I’m (obviously) not really a jack user…


#15

In my own variant of the jack support for juce, I export two audiodevicetypes:
“Jack (auto-connect)”
"Jack (no auto-connect)"
That way the users can pick up the one they prefer, the default being auto-connect. The number of output ports is also fixed by the application.


#16

Ah, that’s a good solution!


#17

Excellent!

But why support Jack only for Linux?

Jack works excellently both in Windows and MacosX as well!


#18

Because there are a finite number of hours in the day, and I need to use some of them for sleeping and having a life. Feel free to get it going and contribute!


#19

finally ! going to test this, and thanx for including part of my classes here !

cheers


#20

WHOOOHOO!

very nice :slight_smile:

one thing that kept me from updating to the tip were my custom jack modifications…
now i finally come around to try to include the git tip and it’s allready there! excellent!
haven’t been testing it very much so far, but my project seems to run fine and connects to my jack server without problems.
Thanks a lot jules!

now only the jack transport stuff is missing.
which files do i have to include to get access to the JackAudioIODevice definitions?
i need to gt the “jack_client_t* client;” member to use my transport code, but only including the standard juce.h i get “JackAudioIODevice was not declared…” errors.

anyway - nice work!

(by the way… my redraw problems are gone with the tip version, and also the glitches i had when building the 1.5 version in linux.
I’m also very happy to see that it seems all the other linux bugfixes have finally found their way into the source. clipboard is working fine with the new version, as well as the native title bars)

comboy