Building a JackTrip Server on 64bit RPi Bullseye

[Mark Smith]

Hi,

I have followed the instructions and built the jacktrip software to try to run a server.

But only one channel, the left, works using the full mix mode - when I check with qjackctl it shows only one receive component:

I also notice the number of channels (always set to 2) cannot be altered in Server mode. Surely this should be 4 for server mode??? And how is this number used for multiple clients?

I am probably doing many ill advised things here but was wondering if any kind person could shed any light on this?

Thankyou

[BG Lyon]

Hi Mark,

I’m not sure if this is helpful at all but when I connect with people who only have mono on their system, I have to route my send manually both to their one receive. I don’t know if this address is your concern at all but in any case if it does great and if it doesn’t please disregard.

--
You received this message because you are subscribed to the Google Groups "jacktrip-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jacktrip-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jacktrip-users/7b50a39d-dd2d-495a-9d66-13ba49c749d0n%40googlegroups.com.

[Mark Smith]

Hi Bethly,

Thankyou - that was helpful for me - the system default seems to be 'mix-to-mono', as seen on the Jacktrip servers - which I didn't understand!

So, in my band we all have stereo mixers - so I would like to keep the stereo everywhere if possible. The default configuration, as you say, takes the stereo but only forwards the left channel. I will hunt for the settings that keeps the stereo for both in and out. I modified the code to add the missing receive buffer but the sound didn't route to it - I guess there is a setting somewhere - some more code diving...

Thanks again!

[BG Lyon]

Hi Mark,

Hmmm… i’m using an older version of JackTrip I think, and I’m wondering if that has something to do with it. When I’m routing to somebody who has stereo configuration, I’m able to send and receive both channels without making any changes at all. The only time I need to manually route is when my peer is only able to receive a mono signal. 

Beth

To view this discussion on the web visit https://groups.google.com/d/msgid/jacktrip-users/54d9245b-dfb3-4116-b88f-c7e5e74aada7n%40googlegroups.com.

[Mike O'Connor]

hi Mark,

i'd be happy to jump on Zoom and help you puzzle through this one.  i think that might be easier that firing questions at you over the list.

if you're game, let's take this off-list and figure out a time...

mike

On Dec 28, 2021, at 3:36 PM, Mark Smith <superst...@gmail.com> wrote:

Hi,

I have followed the instructions and built the jacktrip software to try to run a server.

But only one channel, the left, works using the full mix mode - when I check with qjackctl it shows only one receive component:

<1ch.png>

I also notice the number of channels (always set to 2) cannot be altered in Server mode. Surely this should be 4 for server mode??? And how is this number used for multiple clients?

I am probably doing many ill advised things here but was wondering if any kind person could shed any light on this?

Thankyou

--
You received this message because you are subscribed to the Google Groups "jacktrip-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jacktrip-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jacktrip-users/7b50a39d-dd2d-495a-9d66-13ba49c749d0n%40googlegroups.com.

<1ch.png>

[Mark Smith]

Hi Mike,

Thanks for your kind offer! I had some time over the holidays and I think I've puzzled out a few things...

Firstly the standard image for the the RPi with the HiFiBerry hat sends only the the left channel, to whatever server. I can see the client uses 1 channel out and in on its command line.

When the stream arrives at the server, the software by default is configured to only connect the one incoming channel to its corresponding single outgoing channel - the right channel by default in the existing code is not connected.

So to have two channels it would be required for the client to send both channels, by using the correct command line. I tried modifying the command line but the update mechanism overwrites the change on reboot and puts it back to one channel.

And for the server, if two channels were sent (not sure what the effect on bandwidth would be?) the server would send them out again. The server is fixed to two output channels in the code.

Another option would be to do what I suspect the official servers do; connect the one incoming channel to the two outgoing ones, probably by using the SuperCollider mixer which is connected up to the web interface. Using a software mixer and panning the incoming mono stream would also be an option for a user server. Another option is to make the Jack connections by hand using the 'no connection' option or manually configure Jack as I think Beth was saying she does .

I would rather not use a software mixer if possible; it means extra latency and complexity and means fiddling with software on the server. Using the manual connection option also means extra fiddling.

A better option, IMHO, would be to change the software code to connect all the possible inputs to outputs for both the server and client software. I can do this for the server code (on my self built version) but  I can't easily change the standard client image because of the auto updates.

I have changed my server code to achieve this, it's quite complicated code (for my brain), and I have not tested most of the potential scenarios except my own. I will suggest this option to the people doing the coding to see if they might include some similar code to do this in the released product. I've attached the code if anyone is interested.

So, to be clear my code attempts to connect all outputs to inputs in the software automatically giving stereo (or more) whenever more outputs than inputs are available.

Does anyone have any comments?

Thankyou

[Mike O'Connor]

hi Mark,

let me pepper you with a few dumb questions...  ;-)

in your first note, you mention "instructions to build Jacktrip."  can you share the link to the instructions you followed?  there are several versions out there.  

there are prebuilt installer/binary files available for most platforms as well.  it might be good to give one of those a try for your server -- here's the link to open-source Jacktrip stuff on the CCRMA site.  have a look at the 'installers and/or binary executable files for Linux, OS X and Windows' link.

https://ccrma.stanford.edu/software/jacktrip/

i'll stick a few more questions into your more recent post...

On Jan 1, 2022, at 5:30 PM, Mark Smith <superst...@gmail.com> wrote:

Hi Mike,

Thanks for your kind offer! I had some time over the holidays and I think I've puzzled out a few things...

Firstly the standard image for the the RPi with the HiFiBerry hat sends only the the left channel, to whatever server. I can see the client uses 1 channel out and in on its command line.

same here -- what link are you using to grab that binary?  

i'm a little surprised that the client makes that 1-channel decision on its own.  the default for a command-line client is to send 2 channels. 

is this client being controlled by the Jacktrip Virtual Studio environment?  if so, i'm not familiar with how that works at all -- and your question might be better directed to the community that is more familiar with that world.  here's the link

https://community.jacktrip.org/

When the stream arrives at the server, the software by default is configured to only connect the one incoming channel to its corresponding single outgoing channel - the right channel by default in the existing code is not connected.

are we talking about the server software here?  the default is also to listen on 2 channels and connect corresponding signals.  there are several ways to set up the routing on a server, but the default is to mix the incoming audio of a player and send it to all others, and send a mix of all the other players back to the player.  this is called 'server to clients' in Jacktrip and sometimes called 'mix-minus' by folks who are keen on audio-routing.  here are the command-line options for this.

 -p, --hubpatch # (0, 1, 2, 3, 4, 5)      Hub auto audio patch, only has effect if running HUB SERVER mode,

                                          0=server-to-clients, 

                                          1=client loopback, 

                                          2=client fan out/in but not loopback, 

                                          3=reserved for TUB, 

                                          4=full mix, 

                                          5=no auto patching 

                                          (default: 0)

So to have two channels it would be required for the client to send both channels, by using the correct command line. I tried modifying the command line but the update mechanism overwrites the change on reboot and puts it back to one channel.

ah...  this is definitely looking like a Virtual Studio conversation...  we here in open-source land do our own updates.  ;-)

And for the server, if two channels were sent (not sure what the effect on bandwidth would be?) the server would send them out again. The server is fixed to two output channels in the code.

there's quite a bit of flexibility to specify channel configuration when running the server from the command line.  

 -n, --numchannels #                      Number of Input and Output Channels (# greater than 0, default: 2)

     --receivechannels #                       Number of receive Channels from the network (# greater than 0)

     --sendchannels #                          Number of send Channels to the network (# greater than 0)

i can't find a way to set these options in the GUI for Jacktrip.  but it sounds like the default (stereo) is what you're after anyway.

by the way -- the effect on bandwidth is to double it.

Another option would be to do what I suspect the official servers do; connect the one incoming channel to the two outgoing ones, probably by using the SuperCollider mixer which is connected up to the web interface. Using a software mixer and panning the incoming mono stream would also be an option for a user server. Another option is to make the Jack connections by hand using the 'no connection' option or manually configure Jack as I think Beth was saying she does .

Qjackctl to do that routing too.  but i think the root cause of your puzzler is the clients sending/receiving mono signals.  probably better to go after that one first.

I would rather not use a software mixer if possible; it means extra latency and complexity and means fiddling with software on the server. Using the manual connection option also means extra fiddling.

yep.  the default server will do mix-minus between all players in stereo.  best to concentrate on getting stereo signals to the server...  that's the default for the open-source Jacktrip client -- so again, it may be better to ping the folks in Virtual Studio land about how to do that.

A better option, IMHO, would be to change the software code to connect all the possible inputs to outputs for both the server and client software. I can do this for the server code (on my self built version) but  I can't easily change the standard client image because of the auto updates.

ugh...  forking Jacktrip code outside the normal development cycle strikes me as a really bad idea.  danger danger!  :-)

To view this discussion on the web visit https://groups.google.com/d/msgid/jacktrip-users/d4e3f23c-bc5a-4153-aacb-1ef4718b92f4n%40googlegroups.com.
<npatcher.txt>

[Mike O'Connor]

bah...  shows how little i know about the Jacktrip GUI.  i was looking at the server, not the client.  here's how you set the number of channels in the client.  give that a go, against a default Hub Server and see how things work...

<shakes head in shame....>

To view this discussion on the web visit https://groups.google.com/d/msgid/jacktrip-users/BC0009F1-DC61-4AE4-866A-57C15C53B06B%40gmail.com.

[Mark Smith]

Hi Mike,

I used these instructions to build the current latest code (when I got it) from github v1.4.3 https://help.jacktrip.org/hc/en-us/articles/1500009727561-Build-a-Raspberry-Pi-4B-Computer-with-JackTrip for my separate RPi server

And I'm using the pre-build binary available here: https://help.jacktrip.org/hc/en-us/articles/360055205313-Virtual-Studio-Image-for-Raspberry-Pi for my RPi Analog Bridge with HiFi Berry hat that I built.

In my testing I found specifying the number of channels ONLY works for the client command line - when using the server option the channel settings are ignored and stay as two out and whatever the client send in. But if the client sends only one only one channel is connected giving only the left on my headphones. The patch algorithm is coded to only connect instances where there is both an IN and an OUT.

The pre-built RPi image client option uses the pre-set command line:

-t -z --udprt --receivechannels 2 --sendchannels 1 -C XX.XXX.XXX.XXX --peerport 4464 --bindport 4464 --clientname hubserver --remotename e45f017c378e -q auto -Oio

(where the Xs are my IP address)

These are held in a file called: /tmp/default/jacktrip on the RPi pre-built image.

If you edit this file manually it will be overwritten by the auto-update. However I can now see that setting the stereo option on the server in the app.jacktrip.servers page seems to somehow cause the

receivechannels to be set to two for some reason.

So I've requested the code be (officially) modified to connect all the inputs and outputs in the software, or at least to make the server out to be connected as stereo when only one input and would also like client to somehow allow its sent channels

(i.e. the above command line to have --sendchannels 2 ) to also allow stereo, if we have the bandwidth, without breaking the autoupdate.

Hopefully I've got this right...

Thankyou everyone for your time in making jacktrip such an amazing system!

[Mark Smith]

P.S. - it seems the developers have (partially) accepted my suggestion https://github.com/jacktrip/jacktrip/pull/450

[Mike O'Connor]

ah.  thanks for the link to the thread on GitHub.  you're in good hands with Aaron.

mike

To view this discussion on the web visit https://groups.google.com/d/msgid/jacktrip-users/7df56987-2996-472d-9133-3d82336513b8n%40googlegroups.com.

[Mark Smith]

Please note I have found my code above doesn't work with multiple clients so best not to use it - if you want this functionality asap you can pull it from the git repository developers branch with a little tweaking. Hopefully the official version will be made available by the normal release cycle.

[Aaron Wyatt]

Should be out now as 1.5.0. There's an "upmix mono clients to stereo" checkbox in the GUI when running as a hub server and the equivalent command line switch is -u or --upmix. (In conjunction with choosing whichever patching mode you wanted to use.) If you're really dead set on implementing a full round robin system for connecting channels, you were half way there with the code that you have. The comment that you added in the final loop is where you'd need to add the rest of the logic behind things - this will ensure that the output of existing clients will be properly hooked up and sent to new clients as they join the server. (I would recommend storing the number of inputs and outputs for each client as they connect in a QHash or similar object to make the job of doing this easier.) But I think beyond the common case of mono to stereo, autopatching will be of limited use if you have people connecting with more esoteric combinations of mismatching channel numbers. Then you'd probably need a custom solution using remote client names (-K or in the advanced options tab) and a program like jack-matchmaker. (Happy to answer any questions you might have about that if needed.)

Cheers,

A

[Synthia Cynthia Payne]

I love watching you guys work. This feature has been on my mind.
Huzzah and thank you all for your diligence.

synthia

>> -t -z --udprt --receivechannels *2* --sendchannels *1* -C

>>>>> <https://groups.google.com/d/msgid/jacktrip-users/7b50a39d-dd2d-495a-9d66-13ba49c749d0n%40googlegroups.com?utm_medium=email&utm_source=footer>.

>>>>> <1ch.png>
>>>>
>>>>
>>>> --
>>>> You received this message because you are subscribed
>>>> to the Google Groups "jacktrip-users" group.
>>>> To unsubscribe from this group and stop receiving
>>>> emails from it, send an email to
>>>> jacktrip-user...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/jacktrip-users/d4e3f23c-bc5a-4153-aacb-1ef4718b92f4n%40googlegroups.com

>>>> <https://groups.google.com/d/msgid/jacktrip-users/d4e3f23c-bc5a-4153-aacb-1ef4718b92f4n%40googlegroups.com?utm_medium=email&utm_source=footer>.

>>>> <npatcher.txt>
>>>
>>>
>>> --
>>> You received this message because you are subscribed
>>> to the Google Groups "jacktrip-users" group.
>>> To unsubscribe from this group and stop receiving
>>> emails from it, send an email to
>>> jacktrip-user...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jacktrip-users/BC0009F1-DC61-4AE4-866A-57C15C53B06B%40gmail.com

>>> <https://groups.google.com/d/msgid/jacktrip-users/BC0009F1-DC61-4AE4-866A-57C15C53B06B%40gmail.com?utm_medium=email&utm_source=footer>.

>>
>>
>> --
>> You received this message because you are subscribed to the
>> Google Groups "jacktrip-users" group.
>> To unsubscribe from this group and stop receiving emails from
>> it, send an email to jacktrip-user...@googlegroups.com.
>> To view this discussion on the web visit

>> https://groups.google.com/d/msgid/jacktrip-users/7df56987-2996-472d-9133-3d82336513b8n%40googlegroups.com
>> <https://groups.google.com/d/msgid/jacktrip-users/7df56987-2996-472d-9133-3d82336513b8n%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "jacktrip-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to jacktrip-user...@googlegroups.com

> <mailto:jacktrip-user...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/jacktrip-users/f80d01db-a80a-409d-bc42-4567278c6a40n%40googlegroups.com
> <https://groups.google.com/d/msgid/jacktrip-users/f80d01db-a80a-409d-bc42-4567278c6a40n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Mike O'Connor]

i agree! i just fired it up on the Mac and admired the Bright Shiny New button! i'll test it in a sec on Linux with an actual session...

but... i was wondering about the numbering. i kinda wasn't paying attention when this came up the Github thread but i guess i would have expected to see this one in the 1.4.n series rather than a bump all the way up to 1.5.0. do you have strong feelings about this Aaron? 1.5.0 is scary/big to us user-types. a 1.4.n increment is more in line with the scale/impact of this change IMHO...

mike

> To view this discussion on the web visit https://groups.google.com/d/msgid/jacktrip-users/3fb99bc5-a627-e033-d645-c884bbece8be%40gmail.com.

[Mike O'Connor]

ah! my mental model of this was wrong. i expected it to behave like the Broadcast mode, where JT would spawn a new connection from the player and deliver the same signal to both. but that's not what's happening -- it's doing the upmixing within Jacktrip, right?

another thing that occurs to me. if the player needs to get upmixed into a stereo mix, don't they also need it to be downmixed back to mono on their receive side? otherwise, the player is only gonna hear the left channel of the mix, which might be tough if some of the players are panned hard-right in the mix. that gets further trickier because the mixing may introduce some phase issues that aren't too bad in stereo but get pretty rugged when mixed to mono. some puzzlers for ya. ;-)

and for me too -- i've got a little auto-connect-players script in the PGJTT that's the perfect place to create this capability. the path to upmixing (by replicating the mono connection on the player's other channel) is pretty clear to me, but the phase issues in the downmix require further contemplation. i may just slam the downmix in and see how it sounds.

mike

> To view this discussion on the web visit https://groups.google.com/d/msgid/jacktrip-users/48B2E621-6307-4CF6-B5D7-65BAA18CC675%40gmail.com.

[Aaron Wyatt]

I would have thought it was more of a point release too, but I think it was decided in a dev meeting at some stage that those are only for bug fixes. So any new features see a bump in the minor version number. Hopefully downmixing is a slightly less pressing issue: because of the asynchronous nature of most people's connections, they can usually handle receiving a stereo signal even when their upload bandwidth only allows them to send a mono one. (But it is probably something worth investigating in the future.) For the moment at least it means that clients sending a mono signal aren't just going to be panned hard left in everyone's output as they would have been previously.

A

[Aaron Wyatt]

And the upmixing is done through the patching. So instead of just being connected to the first available channel, mono signals are now patched through to the first two channels. You can see the difference in patching in full mix mode between a mono and stereo client in the graph screenshots below. (Both clients receive a stereo signal back from the server, so both have two send ports.)

First with upmixing disabled:

No audio from the mono client appears in the right channel of other clients or in the client's own loopback.

Then with it enabled:

The audio from the mono client appears in both channels.

Hope that clears up how it works.

A

[Mike O'Connor]

i've got a couple clients coming in and here's what i see...  where am i going astray?  my mono-player is simulating 1 channel in and out -- that's typically how we bring those in.

here's server-to-clients mode...

and here's loopback...

On Jan 3, 2022, at 8:26 AM, Aaron Wyatt <psibo...@gmail.com> wrote:

And the upmixing is done through the patching. So instead of just being connected to the first available channel, mono signals are now patched through to the first two channels. You can see the difference in patching in full mix mode between a mono and stereo client in the graph screenshots below. (Both clients receive a stereo signal back from the server, so both have two send ports.)

First with upmixing disabled:

<upmix2.png>

No audio from the mono client appears in the right channel of other clients or in the client's own loopback.

Then with it enabled:

To view this discussion on the web visit https://groups.google.com/d/msgid/jacktrip-users/54d462bb-7e76-4049-b952-bb996f8ee0d8n%40googlegroups.com.
<upmix.png><upmix2.png>

[Mike O'Connor]

ah!  i'd have lobbied for your point of view.  

partly from the standpoint that it would be nice to have a way to road-test new features without dragging everybody up a whole minor version number.  

and partly because my typical user views upgrading Jacktrip as a huge complicated thing that's hard to undo if things go kerflooey.  so it's a hard sell, especially in the middle of a season.  a third-level change is easier because it feels much safer and less disruptive.  

good to know about the new approach.

is Chris's page at CCRMA ( https://ccrma.stanford.edu/software/jacktrip/ ) the place i should have people look for the current/stable release?  it's pointing at 1.4.2 right now.

To view this discussion on the web visit https://groups.google.com/d/msgid/jacktrip-users/26f81146-c162-4319-bed0-384b063778b5n%40googlegroups.com.

[Aaron Wyatt]

Yes, either Chris' page (which looks like it's up to date now) or the github releases page (https://github.com/jacktrip/jacktrip/releases).

Server to clients mode doesn't use the patcher code, so it isn't being upmixed at the moment. (But I should see if I can fix that.) Otherwise it looks like loopback is doing exactly what it should be doing. Is there any reason those sending mono to you can't receive a stereo signal? (Even if downmixing is implemented, they'd likely still have a better experience if they could receive a stereo feed.)

A

[Mike O'Connor]

ah!  yep, CCRMA's page is up to date...  thanks to whoever did that...

to answer your second question first, i haven't worked with an ensemble that's upgraded from 1.3 to 1.4 yet, so i just rigged up the demo the way the folks i work with do it.  my hope is to see the mono participant upmixed for the other clients without any Qjackctl-rasslin'.  

i didn't realize that the patcher doesn't run in the default (Option 0) server config.  i never have really had a good grasp on the difference between the default Option 0 (server to clients) and options 2 and 4 (client fan-out/no loopback and full-mix respectively).  isn't option 0 just providing the option for the server to be a player along with all the others?  i have assumed that a silent server in an option 0 config is just like option 2. 

i just found these nifty CCRMA comparison pictures that show the respective layouts (for those trying to follow along).  as i look at these i see the difference in the routing (more-direct - no trip through the System ports).  as i say -- i clearly need some education here.  especially wondering why option 0 is the default rather than option 2.

i'll fire up my little minion servers again tomorrow and give an option-2 server a run at this -- and run some asymmetrical mono clients as well.

thanks again -- neat stuff.

mike

To view this discussion on the web visit https://groups.google.com/d/msgid/jacktrip-users/0012bb92-6b89-4ad9-a504-743c414664f8n%40googlegroups.com.

[Aaron Wyatt]

Well, you'll definitely see the mono client upmixed if you're in client fan out/in or full mix modes, so it should work as expected. Mode 0 is kind of a weird mode that's not all that useful in a lot of cases. No patching occurs between the clients themselves, so the server can hear everyone and can be heard by everyone, but none of the clients can hear each other. It's almost like there needs to be a version of full mix and client fan out/in that includes the server. I'll raise it with the others.

A

[Mike O'Connor]

thanks for living through my dumb questions.  i've been manually-routing server audio since i first learned Jacktrip and never understood the distinction between the modes.

it would be interesting to discuss the pros and cons of having additional modes where the server is being run by a person who is also participating in the session.  i may be alone in doing it that way -- out of ignorance rather than design.  it may not be worth confusing folks with that additional set of options if techie/player is an extreme edge case.  

to confirm -- your update works as advertised.  thanks for that as well.

this is the view from the server (option 2 - fan-out, no loopback).  the mono Player1 gets routed to both channels of the stereo Player2.  

and here's the stereo Player's view (i'm doing the routing manually there, so i've left it out of the picture -- the main point is that mono Player1 is indeed arriving on both channels)

To view this discussion on the web visit https://groups.google.com/d/msgid/jacktrip-users/aaf875b2-ad08-4da9-b03b-92ccf15a899en%40googlegroups.com.

[Aaron Wyatt]

If you're interested in trying it out, the builds on my page (https://www.psi-borg.org/other-dev.html) have the ability (at least in the GUI) to add the server into the client fan out/in and full mix patches now. (Although your screenshots do look a little linux-y, and ironically that's the one platform I don't maintain binaries for in spite of using it almost exclusively.) If you're comfortable with building from source you can try it out on the patcher-enhancements branch.

A

[Mike O'Connor]

nifty!  i've got a gaggle of Macs back here at home so i threw a copy on one and tried it out.  it works fine.

and...  it's tricky -- my first run was an instant feedback machine.  it's the Dreaded Channels 1&2 Problem.  where do all apps put their output by default?  channels 1&2.  where does Jacktrip put it's output by default?  Channels 1&2.  that makes things complicated from a routing standpoint.

i gotta scurry off to my day, but i think we'd best not roll this one just yet.  i gotta kinda puzzle this one through.

thanks!

mike

To view this discussion on the web visit https://groups.google.com/d/msgid/jacktrip-users/8c056278-e72a-4f56-9730-e48cbdeb8733n%40googlegroups.com.

[Mark Smith]

Hi All,

Thanks very much for the new version - I have tested it and it works fine for me and does exactly what I wanted! I was trying to make the solution a general case for use by others when more than 2 channels are available but as pointed out the round robin doesn't make sense in the real world.

One other related suggestion I had was for the software to print the number of input and output channels, both available and patched when started, and whenever a client connects - that might help people with some quick fault finding?

The next issue I would like to tackle is to somehow allow stereo streams coming out of the bridge but still keep image as standard (i.e. the setting is persistent and not overwritten by the update process) - perhaps also having another toggle on the app server interface that controls the option?

Then I was wondering about an internet radio interface for live performances...

Anyway those are for other threads...

First band practice tonight for a while - now we are set up to use Jacktrip!

Thankyou!

[TJGigs]

"discuss the pros and cons of having additional modes where the server is being run by a person who is also participating in the session."

I found the only way to do client side mixing by each participating client of all individual receive channels is to have "one of the participants be the server" with a custom automatically applied patch map (qjackctl in my case) and a predefined discrete instrument channel mapping convention... 

I looked quickly at Jacktip 1.4 but did not see anything that would allow me to change the approach of one participant needing to be the server to achieve client side individual mixing. 

Unless I missed something that I could use is JT1.4? Anyone else do this?

This is the doc that describes why/how I did this using 1.3

[Mike O'Connor]

hi TJ

your setup (as shown on page 10 of your diagram) is allowing *each* player to build a custom mix for themselves.  in order to do that, you provide peer-to-peer connections between each player, including yourself.  that way they each have separate audio channels for every other player and everybody can build a mix on their end  

what JT provides is a single mix of all other players to each player (aka mix-minus).  there's only one connection between the server and each player.  the good news is -- less bandwidth.  but individual players can't vary the mix to their own need.  here's what JT will do for you in patch mode 2 (client fan out/in, no looping)

 

what you would then have to do is manually add yourself to the routing so that you'd be included in the mix (the blue lines in this next picture).  but you would all get the same mix, and each of you would have to set your level during soundcheck.  

what Aaron has added is the ability to have Jacktrip put those blue lines in automatically in some cases.  i think at a minimum it should probably be a selectable option, not an all-the-time thing, because of the collisions that can happen on Channels 1-2 of an interface.  

your picture provides a good example of the collisions i'm talking about.  if you flipped the switch and told JT to autoroute, your interface (portaudio) would probably be a little surprised when JT routed a mix of all other players into it on Channels 1-2, since right now you've already got voicemeeter coming into it on 1-2.  likewise, JT would take your Mic1/Mic2 pair and send those off to all other players.  again, a surprise. that's why i'm cautious about turning this on in all cases -- especially without warning people that it was coming.   

clear as mud?

mike

To view this discussion on the web visit https://groups.google.com/d/msgid/jacktrip-users/6fbd7d84-f82d-4166-92a8-c04e9de98e7an%40googlegroups.com.
<JackTripServerMixing.pdf>

[Aaron Wyatt]

Which is why it's off by default. Effectively all it's meant to do is act as a convenient way for the server to be included in the mix for people who have a relatively straight forward set up. So this is perfect for someone who, if they were running as a client, has an audio set up that would work with the default patching of inputs and outputs that occurs if you don't disable the "connect default audio ports" checkbox or use -D on the command line. The reality is that auto patching modes will always be of limited use once you have a more complicated set up, and that's where things like jack-matchmaker or the QJackCtl patchbay come into play, like in TJ's set up. But they do provide a convenient starting point.

Aaron

[Mike O'Connor]

ah!  that's the ticket.  i see that "connect default audio ports" tickbox under the Hub Client.  is it also supposed to be under Hub Server so's to keep people out of trouble?  that would solve the "unexpected change in behavior - unexpected routing-collisions" puzzler i'm concerned about.  that way a person like TJ could consciously decide whether to switch over to letting JT route their system-outs when they're running a server on their performance machine.

here are the Hub Server screens i see on the 1.5.1 that loaded up on a Mac.  does that mode need a tickbox like the Client's got under Advanced Options?

To view this discussion on the web visit https://groups.google.com/d/msgid/jacktrip-users/04859e5d-ec8a-4652-9170-eeb5e3647ff3n%40googlegroups.com.

[Aaron Wyatt]

Is this the version from my site? Because it's an older version that won't be patching in audio from the server. (Maybe an outdated version of the page was being cached somewhere?) In the about window the build number should be 2022010700.

A

[Mike O'Connor]

ah!  a quick note to let you know what's up.  i was using a version from the 5th.  the new one (the 7th) has the tickbox i was hoping for.  i'll run a test in a bit, but i wanted to set your mind at ease.  i've got a stack of stuff to get through before i can build up another test scenario.  nice phrasing, i think "include the server in patching" captures the idea just right.

To view this discussion on the web visit https://groups.google.com/d/msgid/jacktrip-users/6d529bf7-5ae7-45e9-8e87-62d02d4da376n%40googlegroups.com.

[Mike O'Connor]

OK.  got a chance to spin up a couple clients.  it all looks fine.  but...

i'm thinking we may want to revisit the "mono clients get stereo downmix" issue.  the mono player is only going to hear the left channel of all stereo participants.  presumably the stereo folks are doing that for a reason and the mono people are likely to (somewhat mysteriously) miss anything that's panned right.  maybe another tickbox to offer that option?  maybe make it the default?  i'm leaning toward the view that a little phase-cancellation may be preferable to not hearing that channel at all.

duly noted that all of this is for the people who want to avoid the complexity of custom routing and/or asymmetrical clients.  

which then gets me to a long-held dream -- which would be the ability for each player to *pick* which channels they send and receive on when they're running multi-channel interfaces.  Sonobus, Jamulus and etc. let a person choose those channels when they set up their connection, which is a huge help in avoiding the dreaded Channel 1-2 collisions with other apps (like DAWs) that default to sending/receiving on Ch1-2 or other apps (like Quicktime and GarageBand) which *only* send on Ch1-2.    

in the example above i'd love to be able to specify that JT send (capture) audio from ch5-6 of the interface and route incoming audio to (playback) channels 3-4.  both GUI and command-line por favor.  oh, and the option for marshmallows and chocolate sprinkles would great.  ;-)

On Jan 7, 2022, at 9:04 AM, Mike O'Connor <oconn...@gmail.com> wrote:

ah!  a quick note to let you know what's up.  i was using a version from the 5th.  the new one (the 7th) has the tickbox i was hoping for.  i'll run a test in a bit, but i wanted to set your mind at ease.  i've got a stack of stuff to get through before i can build up another test scenario.  nice phrasing, i think "include the server in patching" captures the idea just right.

<JT1.5.1 screen - 2nd pull.jpeg>