File renaming, update README.
git-svn-id: http://subversion.jackaudio.org/jack/jack2/trunk/jackmp@2914 0c269be4-1314-0410-8aa9-9f06e86f4224
This commit is contained in:
sletz
parent
9f36ed10fe
commit
af9176feaa
|
|
@ -2,7 +2,7 @@
|
|||
jackdmp for Linux, MacOSX and Windows
|
||||
--------------------------------------
|
||||
|
||||
jackdmp is a C++ version of the Jack low-latency audio server for multi-processor machines. It is a new implementation of the jack server core features that aims in removing some limitations of the current design. The activation system has been changed for a data flow model and lock-free programming techniques for graph access have been used to have a more dynamic and robust system.
|
||||
jackdmp is a C++ version of the JACK low-latency audio server for multi-processor machines. It is a new implementation of the JACK server core features that aims in removing some limitations of the current design. The activation system has been changed for a data flow model and lock-free programming techniques for graph access have been used to have a more dynamic and robust system.
|
||||
|
||||
- jackdmp use a new client activation model that allows simultaneous client execution (on a smp machine) when parallel clients exist in the graph (client that have the same inputs). This activation model allows to better use available CPU on a smp machine, but also works on mono-processor machine.
|
||||
|
||||
|
|
@ -37,6 +37,7 @@ Important compilation options :
|
|||
- the --dbus flag must be defined at configure time to compile the jackdbus executable. If the "automatic start server option" is used by clients, jackd server will be started using the dbus service.
|
||||
|
||||
|
||||
----------------------------
|
||||
Known problems, limitations
|
||||
----------------------------
|
||||
|
||||
|
|
@ -52,7 +53,7 @@ The package contains :
|
|||
|
||||
- the compiled binaries with "install" and "remove" scripts located in bin/osx
|
||||
- the source code with an XCode project
|
||||
- the component needed to use CoreAudio applications with Jack (the JackRouter Jack/CoreAudio bridge)
|
||||
- the component needed to use CoreAudio applications with JACK (the JackRouter JACK/CoreAudio bridge)
|
||||
|
||||
Starting with 0.70 version, the OSX project can compile 32/64 bits binaries for PPC and Intel machines. On a 64 bits machine, using the "jackdmp" in a terminal will start the 64 bits version. Using the "arch" command possibly allows to force starting in 32 bits (see man arch). The JackPilot and JackRouter binaries are now also released as 32/64 bits versions for PPC and Intel machines. By default the JackPilot application will start in 32 bits mode (even on a 64 bits machine) and launch the 32 bits jackdmp. Unchecking the "Launch in 32 bits mode" box in the JackPilot info (GetInfo = %I in the Finder...) allows to start JackPilot in 64 bits then launch the 64 bits jackdmp version. Very few audio applications are already 64 bits aware: Apple AU Lab (included in Developer tools) can be launched in 64 bit, here again by unchecking the "Launch in 32 bits mode" box in the AU Lab info.
|
||||
|
||||
|
|
@ -60,8 +61,9 @@ WARNING !! WARNING !!
|
|||
|
||||
Users of the "official" JackOSX package (found at www.jackosx.com) MUST uninstall JackOSX (using the script located in /Applications/Jack) before installing and testing jackdmp. The "official" JackOSX package can then be re-installed by using the JackOSX installer again.
|
||||
|
||||
---------------------------------
|
||||
Mac Intel special considerations
|
||||
--------------------------------
|
||||
---------------------------------
|
||||
|
||||
- New Mac Intel use 2 different coreaudio device for input/output. Jackdmp cannot directly handle 2 devices to do duplex processing. An "aggregate" device has to be built in this case.
|
||||
|
||||
|
|
@ -85,17 +87,27 @@ The published version uses named event for server/client synchronization. Named
|
|||
|
||||
The binary elements are :
|
||||
|
||||
- jackdmp.exe : the jack server
|
||||
- jackd.exe : the JACK server
|
||||
|
||||
- libjackservermp.dll (and associated libjackservermp.lib library) : the server code, shared by the jackdmp server and drivers.
|
||||
- libjackserver.dll (and associated libjackserver.lib library) : the server code, shared by the jackdmp server and drivers.
|
||||
|
||||
- libjackmp.dll (and associated libjackmp.lib library) : the jack library code, to be linked against by clients.
|
||||
- libjack.dll (and associated libjack.lib library) : the jack library code, to be linked against by clients.
|
||||
|
||||
- jack_portaudio.dll : the PortAudio based backend. The backend components (currently "jack_portaudio.dll" only) are searched for in a "jackmp" folder located with the "jackdmp.exe" server.
|
||||
- jack_portaudio.dll : the PortAudio based backend. The backend components (currently "jack_portaudio.dll" only) are searched for in a "jackmp" folder located with the "jackdmp.exe" server.
|
||||
|
||||
- jack_dummy.dll : the "dummy" driver.
|
||||
|
||||
- jack_net.dll : the NetJack driver.
|
||||
|
||||
- netmanager.dll : the "in server" client NetJack Manager.
|
||||
|
||||
- audioadapter.dll : the network to audio card adapter (to be used on a slave machine started with the NetJack driver).
|
||||
|
||||
- netadapter.dll : the network to audio card adapter (to be used on a slave machine started with an audio driver).
|
||||
|
||||
- jack_connect.exe, jack_disconnect.exe, jack_lsp.exe, jack_metro.exe tools.
|
||||
- jack_connect.exe, jack_disconnect.exe, jack_lsp.exe, jack_metro.exe, jack_load.exe, jack_unload.exe tools.
|
||||
|
||||
- JackRouter.dll version 0.17 : an ASIO/jack driver that allows ASIO compatible applications to become jack clients and access the jack server. ASIO "jackified" applications appear with their names. Ableton Live, Samplitude, Reason, Arturia applications have been successfully tested. To install it, use "regsvr32 JackRouter.dll" in a terminal (use regsvr32 /u JackRouter.dll to uninstall). [VISTA special note: regsvr32 has to be used with "administrator" priviledges to properly register JackRouter.dll (Start Menu -> All Programs -> Accessories -> Right Click on Command Prompt -> Run As Administrator)]. A JackRouter.ini file is used by the driver to read parameters : an [IO] section allows to setup the number of input/output jack ports for the application and a [AUTO_CONNECT] section allows to setup jack ports autoconnection mode to machine input/output.
|
||||
- JackRouter.dll : an ASIO/JACK driver that allows ASIO compatible applications to become JACK clients and access the JACK server. ASIO "jackified" applications appear with their names. Ableton Live, Samplitude, Reason, Arturia applications have been successfully tested. To install it, use "regsvr32 JackRouter.dll" in a terminal (use regsvr32 /u JackRouter.dll to uninstall). [VISTA special note: regsvr32 has to be used with "administrator" priviledges to properly register JackRouter.dll (Start Menu -> All Programs -> Accessories -> Right Click on Command Prompt -> Run As Administrator)]. A JackRouter.ini file is used by the driver to read parameters : an [IO] section allows to setup the number of input/output jack ports for the application and a [AUTO_CONNECT] section allows to setup jack ports autoconnection mode to machine input/output.
|
||||
|
||||
All dll are compiled in "release" mode. The "Debug" folder contains debug version of all dlls and libraries. MSVCRTD.dll and MSVCP60D.dll debug dll are also included.
|
||||
|
||||
|
|
@ -103,14 +115,15 @@ WARNING !! WARNING !!
|
|||
|
||||
Depending of the used interface and driver settings, the PortAudio layer may add additionnal buffering between the real card interrupt and the jack server callback. This usually result in *unregular* calls of the jack server callback (for example if jack server used a 256 frames buffer and the card used a 512 frames, the jack server callback will be called twice every card interrupt). For proper functionning of jack server and clients in this case, the jack server has to be started in "synchronous" mode, using the "-S" parameter.
|
||||
|
||||
----------------------------
|
||||
Known problems, limitations
|
||||
----------------------------
|
||||
|
||||
- Thread handling in still not completely working : jack clients may "hang" when quitting.
|
||||
|
||||
------------------------
|
||||
----------------------------
|
||||
Automatic server launch
|
||||
------------------------
|
||||
----------------------------
|
||||
|
||||
Starting from the 0.64 version, automatic server launch from client is implemented : when the server is not yet running, and if the client uses the "jack_client_open" API, the server will be started automatically. The server configuration is saved in a ".jackdrc" file located in the user home folder. The Qjackctl tool allows to save its configuration in this . jackdrc (setting can be done in Qjackctl Setup/Misc). If no configuration file is found, a default setup will be used.
|
||||
|
||||
|
|
@ -140,6 +153,7 @@ Documentation
|
|||
|
||||
- doxygen generated documentation of the C++ code.
|
||||
|
||||
---------
|
||||
Versions
|
||||
---------
|
||||
|
||||
|
|
@ -183,6 +197,7 @@ Note : To experiment with the -S option, jackdmp must be launched in a console.
|
|||
|
||||
This is a work in progress but the implementation is now stable enough to be tested. jackdmp has been used successfully with the following applications : Ardour, Hydrogen, Jamin, Qjackctl, Jack-Rack, SooperLooper, AlsaPlayer...
|
||||
|
||||
------------------------------------
|
||||
General known problems, limitations
|
||||
------------------------------------
|
||||
|
||||
|
|
@ -0,0 +1,75 @@
|
|||
-------------------------------
|
||||
NetJack for Jackmp
|
||||
-------------------------------
|
||||
|
||||
|
||||
This release includes a version of netjack designed for jackmp. Indeed, the original concept has been completely redesigned to better fit to the jackmp architecture, but also in order to provide additional capabilities, and ultimately a greater robustness.
|
||||
|
||||
This document describes the major changes between those two systems, then a simple how-to for setting up a basic usage of 'netjack2'.
|
||||
|
||||
|
||||
-------------------------------
|
||||
Major changes and architecture
|
||||
-------------------------------
|
||||
|
||||
|
||||
The biggest difference between netjack and netjack2 is the way of slicing audio and midi streams into network packets. For one audio cycle, netjack used to take all audio and midi buffers (one per channel), put butt all of them, then send it over the network. The problem is that a network packet has a fixed maximum size, depending on the network infrastructure (for 100mb, it reaches 1500bytes - MTU of the network). The solution is then to slice those buffers into smaller ones, and then send as many packets as we need. This cutting up can be done by network equipments, but it's more efficient and secure to include it in the software data management. Still this slicing brings another issue : all the packets are not pleased with any emission order and are unfortunately received in a random order, thanks to UDP. So we can't deal with data as it comes, we need to re-bufferize incoming streams in order to rebuild complete audio buffers.
|
||||
|
||||
In netjack2, the main idea is to make this slicing depending on the network capabilities. If we can put only 128 complete audio frames (128 samples for all audio channels) in a network packet, the elementary packet will so carry 128 frames, and in one cycle, we will transmit as many packet as we need. We take the example of 128 frames because it's the current value for 2 channels. This value is determinated by taking the maximum 'power of 2' frames we can put in a packet. If we take 2 channels, 4 bytes per sample (float values), we get 8 bytes per frame, with 128 frames, we now have 1024 bytes, so we can put these 1024 bytes in one packet, and add a small header which identify the packet. This technique allows to separate the packets (in time) so they can be received in the order they have been emitted. If the master is running at 512 frames per second, four audio packets are sent per cycle and the slave deals with them as they arrive. With gigabytes networks, the MTU is larger, so we can put more data in one packet (in this example, we can even put the complete cycle in one packet).
|
||||
|
||||
For midi data, netjack used to send the whole buffer, in this example, 512 frames * 4 bytes per sample and per midi port. Those 2048 bytes are in 99% of the time filled to a few bytes, but rarely more. This means that if we have 2 audio and 2 midi channels to transmit, everything happens as if we had 4 audio channels, which is quite a waste of bandwidth. In netjack2, the idea is to take into account that fact, by sending only the useful bytes, and not more. It's completely unappropriate to overload the network with useless data. So we now have : 99% of the time one midi packet (of a few dozen of bytes), followed by four audio packets (in this example).
|
||||
|
||||
This way of separating audio and midi is quite important. We deal here with network transmissions, and also need to be 'realtime'. We need a system which allow to carry as many audio and midi data streams as we need and can, as if the distant computer was in fact a simple jack client. With all those constraints, we can't avoid packets loss. The better thing to do is to deal with it. But to loose an audio packet is different from skipping a midi one. Indeed, an audio loss leads to audio click, or undesirable, but very short side effect. Whereas a midi data loss can be completely disastrous. Imagine that we play some notes, with sustain, and we loose the sustain 0 value, which stops the effect. The sustain keeps going on on all following notes until the next 'sustain off' event. A simple missing byte can put all the midi system offside (that's the purpose of all the big PANIC buttons on midi softwares...). That's why we need to separate audio (more than one per cycle) from midi (one packet at 99% of the time). If we loose an audio packet, we probably still have an available midi packet, so we can use what we received, even if some audio is missing.
|
||||
|
||||
Those audio and midi packets are preceded by a synchronization packet, which will make the slave directly synchronized on the master's cycle rythm. This packet also carries transport data. Thus it's actually possible to synchronize also transport. This feature goes a little further than in netjack. The idea here is to make every computer of the network fully synchronized on the master's transport. That means the master needs to know the state of every slow sync clients of each of its slaves. The master can now manage the transport state (especially the 'rolling' state) of each slave thus the main transport waits for the last slow sync client before turning 'rolling'. By doing this, the transport can start (roll) in the same cycle for every computers managed by the master.
|
||||
|
||||
|
||||
The second main difference between netjack and netjack2 is the way the two computers (master and slave) synchronise their parametering and launch. In netjack, once the slave configured (by the command line) and launched, it was waiting for the first incoming packet to synchronize (launch its first audio cycle) then run. The two computers needed to be configured separately but with the same parameters to run correctly.
|
||||
|
||||
In netjack2, the only thing you have to set for the slave is its number of in/out midi and audio channels. No more need to choose and set parameters depending on the master, they are automatically determinated and communicated to the slave. This first synchronization step uses a multicast communication, no more need to know by advance all the IP addresses. The slave says on a multicast address "hey, I'm available". A master get the message, and communicate parametering to the slave. Once synchronization done, data transfers can start. Moreover, the master being still listening on the multicast address, it can catch other slaves and manage them (create a jack client to communicate with the slave, and neatily close everything when the slave is gone).
|
||||
|
||||
The loaded internal client is no longer only an interface for the slave, like in netjack. It's now called 'network manager', it doesn't deal with audio or midi, just with some kind of 'network logistical messages'. The manager automatically create a new internal client as soon as a new slave is seen on the network (by sending messages on the multicast address the manager is listening on). This manager is also able to remove one of its internal client as soon as a slave has left the network. This conception allow a complete separation of audio exchanges from parametering and management.
|
||||
|
||||
The 'unloading' of the internal client (the manager) will cause a full cleaning of the infrastructure. The jack clients are all removed from the server, the slave are all turned available again, ready to be cought by another master etc. When a slave quits, it's also automatically removed from the manager's slaves list.
|
||||
|
||||
|
||||
-------------------------------
|
||||
How-to use this ?
|
||||
-------------------------------
|
||||
|
||||
|
||||
Netjackmp is very simple to use. On the master's side, an internal client deals with the slaves, and the slaves themselves are classical jack servers running under a 'network audio driver'. The difference between the two versions is that the master now has a manager, which takes care of the slaves, while listening on the multicast address and create a new master as soon as a slave is available. But everything is transparent to the user, that's why it uses multicast (someone says "hello", and anyone who wants to hear it just has to listen).
|
||||
|
||||
So, just compile and install jackmp as you are used to, on linux, using './waf configure', './waf' and './waf install' as root. On macosx, you can use the xcode project. On Windows, you can use the Code::Blocks workspace (you also have a small script to make an all in one installer).
|
||||
|
||||
On the master, just launch a classical jack server, the period size doesn't matter. Then, load the network manager using jack_load :
|
||||
|
||||
'jack_load netmanager'
|
||||
|
||||
This will load the internal client, which will wait for an available slave (see the message window on qjackctl - or the console output). If you want to listen to a specific multicast socket, you can add some options. To spicify a complete command line, you can use :
|
||||
|
||||
'jack_load netmanager -i"-a xxx.xxx.xxx.xxx -p udp_port"'
|
||||
|
||||
If you set another multicast address or port, you have to set the same on the slave's side. The default value should be working in many cases.
|
||||
|
||||
On the slave, just launch a new jack server using :
|
||||
|
||||
'jackd -R -d net'
|
||||
|
||||
As in a standard backend in Jackmp, you can use '-S' (synchronous mode). The asynchronous mode (without '-S') allows to send the computed data during the next cycle. In synchronous mode, data are sent back at the end of the cycle, that means after the process. You can specify some options, like '-n name' (will give a name to the slave, default is the network hostname), '-C input_ports' (the number of master-->slave channels), '-P output_ports' (the number of slave-->master channels), default is 2 ; or '-i midi_in_ports' and '-o midi_out_ports', default is 0. If you set multicast address or port on the master, you can add '-a xxx.xxx.xxx.xxx' and '-p udp_port'.
|
||||
|
||||
You can also use others network mode, with '-m' option (fast, normal or slow). Fast mode allow a zero latency transmission. This mode means the master waits for its returned data from the slave in the current cycle. This mode is appropriated for 'small' transmissions (only a few channels with a light process on the slave). Normal (default) mode brings one cycle latency. It allow a normal use of the network.
|
||||
|
||||
Slow mode allow a full usage of the whole system. Slow mode brings a two cycles additional latency. This mode allows to send a lot of data on the network, but it also takes into account some process time on the slave, thus the data aren't expected on the master before two cycles, so it's not necessary to wait for them.
|
||||
|
||||
For additional informations, you can go to the NetJack2 Wiki at : http://trac.jackaudio.org/wiki/WalkThrough/User/NetJack2.
|
||||
|
||||
|
||||
-------------------------------
|
||||
What's next ?
|
||||
-------------------------------
|
||||
|
||||
|
||||
The development of netjack continues and some things are always moving... If you use it, please report encountered bugs, ideas or anything you think about.
|
||||
|
||||
If you have any question, you can subscribe the jackaudio developers mailing list at http://www.jackaudio.org/ or join the IRC channel '#jack' on FreeNode.
|
||||
|
|
@ -1,101 +0,0 @@
|
|||
-------------------------------
|
||||
NetJack for Jackmp
|
||||
-------------------------------
|
||||
|
||||
|
||||
This release includes a version of netjack designed for jackmp.
|
||||
Indeed, the original concept has been completely redesigned to better fit to the jackmp architecture, but also in order to provide additional capabilities, and ultimately a greater robustness.
|
||||
|
||||
This document describes the major changes between those two systems, then a simple how-to for setting up a basic usage of 'netjack2'.
|
||||
|
||||
|
||||
-------------------------------
|
||||
Major changes and architecture
|
||||
-------------------------------
|
||||
|
||||
|
||||
The biggest difference between netjack and netjack2 is the way of slicing audio and midi streams into network packets.
|
||||
For one audio cycle, netjack used to take all audio and midi buffers (one per channel), put butt all of them, then send it over the network.
|
||||
The problem is that a network packet has a fixed maximum size, depending on the network infrastructure (for 100mb, it reaches 1500bytes - MTU of the network).
|
||||
The solution is then to slice those buffers into smaller ones, and then send as many packets as we need. This cutting up can be done by network equipments, but it's more efficient and secure to include it in the software data management.
|
||||
Still this slicing brings another issue : all the packets are not pleased with any emission order and are unfortunately received in a random order, thanks to UDP.
|
||||
So we can't deal with data as it comes, we need to re-bufferize incoming streams in order to rebuild complete audio buffers.
|
||||
|
||||
In netjack2, the main idea is to make this slicing depending on the network capabilities.
|
||||
If we can put only 128 complete audio frames (128 samples for all audio channels) in a network packet, the elementary packet will so carry 128 frames, and in one cycle, we will transmit as many packet as we need. We take the example of 128 frames because it's the current value for 2 channels. This value is determinated by taking the maximum 'power of 2' frames we can put in a packet.
|
||||
If we take 2 channels, 4 bytes per sample (float values), we get 8 bytes per frame, with 128 frames, we now have 1024 bytes, so we can put these 1024 bytes in one packet, and add a small header which identify the packet.
|
||||
This technique allows to separate the packets (in time) so they can be received in the order they have been emitted.
|
||||
If the master is running at 512 frames per second, four audio packets are sent per cycle and the slave deals with them as they arrive.
|
||||
With gigabytes networks, the MTU is larger, so we can put more data in one packet (in this example, we can even put the complete cycle in one packet).
|
||||
For midi data, netjack used to send the whole buffer, in this example, 512 frames * 4 bytes per sample and per midi port. Those 2048 bytes are in 99% of the time filled to a few bytes, but rarely more. This means that if we have 2 audio and 2 midi channels to transmit, everything happens as if we had 4 audio channels, which is quite a waste of bandwidth.
|
||||
In netjack2, the idea is to take into account that fact, by sending only the useful bytes, and not more. It's completely unappropriate to overload the network with useless data.
|
||||
So we now have : 99% of the time one midi packet (of a few dozen of bytes), followed by four audio packets (in this example).
|
||||
|
||||
This way of separating audio and midi is quite important. We deal here with network transmissions, and also need to be 'realtime'. We need a system which allow to carry as many audio and midi data streams as we need and can, as if the distant computer was in fact a simple jack client. With all those constraints, we can't avoid packets loss. The better thing to do is to deal with it.
|
||||
But to loose an audio packet is different from skipping a midi one. Indeed, an audio loss leads to audio click, or undesirable, but very short side effect. Whereas a midi data loss can be completely disastrous. Imagine that we play some notes, with sustain, and we loose the sustain 0 value, which stops the effect. The sustain keeps going on on all following notes until the next 'sustain off' event. A simple missing byte can put all the midi system offside (that's the purpose of all the big PANIC buttons on midi softwares...).
|
||||
That's why we need to separate audio (more than one per cycle) from midi (one packet at 99% of the time). If we loose an audio packet, we probably still have an available midi packet, so we can use what we received, even if some audio is missing.
|
||||
|
||||
Those audio and midi packets are preceded by a synchronization packet, which will make the slave directly synchronized on the master's cycle rythm.
|
||||
This packet also carries transport data. Thus it's actually possible to synchronize also transport.
|
||||
This feature goes a little further than in netjack. The idea here is to make every computer of the network fully synchronized on the master's transport. That means the master needs to know the state of every slow sync clients of each of its slaves.
|
||||
The master can now manage the transport state (especially the 'rolling' state) of each slave thus the main transport waits for the last slow sync client before turning 'rolling'.
|
||||
By doing this, the transport can start (roll) in the same cycle for every computers managed by the master.
|
||||
|
||||
|
||||
The second main difference between netjack and netjack2 is the way the two computers (master and slave) synchronise their parametering and launch.
|
||||
In netjack, once the slave configured (by the command line) and launched, it was waiting for the first incoming packet to synchronize (launch its first audio cycle) then run.
|
||||
The two computers needed to be configured separately but with the same parameters to run correctly.
|
||||
|
||||
In netjack2, the only thing you have to set for the slave is its number of in/out midi and audio channels. No more need to choose and set parameters depending on the master, they are automatically determinated and communicated to the slave.
|
||||
This first synchronization step uses a multicast communication, no more need to know by advance all the IP addresses. The slave says on a multicast address "hey, I'm available". A master get the message, and communicate parametering to the slave. Once synchronization done, data transfers can start. Moreover, the master being still listening on the multicast address, it can catch other slaves and manage them (create a jack client to communicate with the slave, and neatily close everything when the slave is gone).
|
||||
The loaded internal client is no longer only an interface for the slave, like in netjack. It's now called 'network manager', it doesn't deal with audio or midi, just with some kind of 'network logistical messages'. The manager automatically create a new internal client as soon as a new slave is seen on the network (by sending messages on the multicast address the manager is listening on). This manager is also able to remove one of its internal client as soon as a slave has left the network. This conception allow a complete separation of audio exchanges from parametering and management.
|
||||
The 'unloading' of the internal client (the manager) will cause a full cleaning of the infrastructure. The jack clients are all removed from the server, the slave are all turned available again, ready to be cought by another master etc. When a slave quits, it's also automatically removed from the manager's slaves list.
|
||||
|
||||
|
||||
-------------------------------
|
||||
How-to use this ?
|
||||
-------------------------------
|
||||
|
||||
|
||||
Netjackmp is very simple to use. On the master's side, an internal client deals with the slaves, and the slaves themselves are classical jack servers running under a 'network audio driver'.
|
||||
The difference between the two versions is that the master now has a manager, which takes care of the slaves, while listening on the multicast address and create a new master as soon as a slave is available. But everything is transparent to the user, that's why it uses multicast (someone says "hello", and anyone who wants to hear it just has to listen).
|
||||
|
||||
So, just compile and install jackmp as you are used to, on linux, using './waf configure', './waf' and './waf install' as root. On macosx, you can use the xcode project.
|
||||
On Windows, you can use the Code::Blocks workspace (you also have a small script to make an all in one installer).
|
||||
|
||||
On the master, just launch a classical jack server, the period size doesn't matter.
|
||||
Then, load the network manager using jack_load :
|
||||
|
||||
'jack_load netmanager'
|
||||
|
||||
This will load the internal client, which will wait for an available slave (see the message window on qjackctl - or the console output).
|
||||
If you want to listen to a specific multicast socket, you can add some options. To spicify a complete command line, you can use :
|
||||
'jack_load netmanager -i"-a xxx.xxx.xxx.xxx -p udp_port"'
|
||||
If you set another multicast address or port, you have to set the same on the slave's side. The default value should be working in many cases.
|
||||
|
||||
On the slave, just launch a new jack server using :
|
||||
|
||||
'jackd -R -d net'
|
||||
|
||||
As in a standard backend in Jackmp, you can use '-S' (synchronous mode).
|
||||
The asynchronous mode (without '-S') allows to send the computed data during the next cycle. In synchronous mode, data are sent back at the end of the cycle, that means after the process.
|
||||
You can specify some options, like '-n name' (will give a name to the slave, default is the network hostname), '-C input_ports' (the number of master-->slave channels), '-P output_ports' (the number of slave-->master channels), default is 2 ; or '-i midi_in_ports' and '-o midi_out_ports', default is 0.
|
||||
If you set multicast address or port on the master, you can add '-a xxx.xxx.xxx.xxx' and '-p udp_port'.
|
||||
|
||||
You can also use others network mode, with '-m' option (fast, normal or slow).
|
||||
Fast mode allow a zero latency transmission. This mode means the master waits for its returned data from the slave in the current cycle. This mode is appropriated for 'small' transmissions (only a few channels with a light process on the slave).
|
||||
Normal (default) mode brings one cycle latency. It allow a normal use of the network.
|
||||
Slow mode allow a full usage of the whole system. Slow mode brings a two cycles additional latency. This mode allows to send a lot of data on the network, but it also takes into account some process time on the slave, thus the data aren't expected on the master before two cycles, so it's not necessary to wait for them.
|
||||
|
||||
For additional informations, you can go to the NetJack2 Wiki at : http://trac.jackaudio.org/wiki/WalkThrough/User/NetJack2.
|
||||
|
||||
|
||||
-------------------------------
|
||||
What's next ?
|
||||
-------------------------------
|
||||
|
||||
|
||||
The development of netjack continues and some things are always moving...
|
||||
If you use it, please report encountered bugs, ideas or anything you think about.
|
||||
|
||||
If you have any question, you can subscribe the jackaudio developers mailing list at http://www.jackaudio.org/ or join the IRC channel '#jack' on FreeNode.
|
||||
|
|
@ -29,20 +29,16 @@ Alternatively using the following command allows to display the names of availab
|
|||
|
||||
Then start jackd with the device you want, by using its name, for example:
|
||||
|
||||
- jackd -R -S -d portaudio -d "ASIO::MOTU Audio ASIO", then start qjackctl. qjackctl will see the jackd server already running and then can be
|
||||
used normally.
|
||||
- jackd -R -S -d portaudio -d "ASIO::MOTU Audio ASIO", then start qjackctl. qjackctl will see the jackd server already running and then can be used normally.
|
||||
|
||||
|
||||
=============================================
|
||||
JackRouter JACK/ASIO driver
|
||||
=============================================
|
||||
|
||||
JackRouter is an ASIO driver that allows any ASIO compatible application to become a JACK client, thus exchange audio with any other "native" or "Jackified" application.
|
||||
This driver is registered in the system by the installer and becomes available in the list of ASIO drivers when the JACK server is running. A "JackRouter.ini" configuration
|
||||
file allows the application to confgiure how the JackRouter driver behaves.
|
||||
JackRouter is an ASIO driver that allows any ASIO compatible application to become a JACK client, thus exchange audio with any other "native" or "Jackified" application. This driver is registered in the system by the installer and becomes available in the list of ASIO drivers when the JACK server is running. A "JackRouter.ini" configuration file allows the application to confgiure how the JackRouter driver behaves.
|
||||
|
||||
- [IO]: the application can obtain any number if JACK input/output ports (not necessarilly equal to the audio card input/output number). [Note that some applications
|
||||
impose their input/output channel number].
|
||||
- [IO]: the application can obtain any number if JACK input/output ports (not necessarilly equal to the audio card input/output number). [Note that some applications force their input/output channel number].
|
||||
|
||||
- [AUTO_CONNECT] : when 1, the application JACK port will automatically be connected to the machine input/output JACK ports.
|
||||
|
||||
Loading…
Reference in New Issue