David Zelinsky

@Eugene Chang, she ended using her Zoom mic in audio interface mode and connecting the headphones to that, which worked. Since it was working that way, she didn't explore further. But another friend later had apparently the same problem, and he tried @John Lovegrove's solution, and it did work. I believe these were both fairly new MacBook Airs. Sorry I can't be of more help.

@Robin Rigby, I'm not sure to which message your "..." refers. But as far as I know, the Jamulus server can only listen on one port, either the default 22124, or specified by "-p" option at startup. In principle it could listen on more than one port at a time, but I don't think the software allows for that. However, this refers to the server-side port. The server will accept connections from any client-side port. On the client side, the "-p" option specifies which source port to use (on the client's...

I should have added that she was using Jamulus version 3.5.5.

I was helping a friend get set up on Jamulus on her new MacBook Air, and she could not get the sound to come through her headphones instead of the computer speakers. The headphones work normally in other apps, just not in Jamulus. These are simple wired headphones, plugged into the headphone jack (not USB). In the Device Settings in Jamulus, there was no option specifically headphone output. She tried "built-in speakers" and "system default", with no effect. Any suggestions would be welcome!

Assuming you're talking about the firewall on the server side, the destination port to open should be whatever port the server is using. The default is 22124 (not 22134, which is the default client port), but can be specified differently with -p option. And yes, I guess you'd need to allow all source ports (above 1024) to be sure PAT'ed clients are never blocked.

Well, it seems I need to eat my words. Everything everyone else said on this thread was absolutely correct, and what I said... not so much. It turns out the reason I was unable to connect a second client behind my NAT was that the port that client was using was not allowed by the server's firewall. I actually did not know that PAT was a thing. I thought the NAT host would use the same local port specified by the client. An afternoon with google and wireshark set me straight. (And only then did I...

Well, it seems I need to eat my words. Everything everyone else said on this thread was absolutely correct, and what I said... not so much. It turns out the reason I was unable to connect a second client behind my NAT was that the port that client was using was not allowed by the server's firewall. I actually did not know that PAT was a thing. I thought the NAT host would use the same local port specified by the client. An afternoon with google and wireshark set me straight. (And only then did I...

Mats, were you connecting to a private server (not appearing in the Central Server list)? And were the two machines both on a private network (different from where the server is) behind a gateway doing NAT (network address translation)? If so, I don't see how it's techincally possible given how NAT works; and it doesn't work when I try it. I should have specified of course that the machines should be on the same private network behind the same NAT gateway.