Welcome to the new FlexRadio Community! Please review the new Community Rules and other important new Community information on the Message Board.
If you are having a problem, please refer to the product documentation or check the Help Center for known solutions.
Need technical support from FlexRadio? It's as simple as Creating a HelpDesk ticket.

Loopback and xdax on a Mac

Gordon, ve7on
Gordon, ve7on Member ✭✭
edited January 27 in SmartSDR for Mac

After many years using Loopback on my Mac I upgraded to the latest version. Unfortunately that was a mistake. Wsjt hears fine but no transmit. I have been playing with it for the past week with no luck. I have been in contact with Rogue Amoeba and they don’t seem to be able to figure it out either.

Does anyone have any suggestions?


Thank you


Gordon, ve7on

Answers

  • Mike WA7IJV
    Mike WA7IJV Member ✭✭
    I also encountered that issue, after updating to Loopback’s new ARK-based release. xDAX TX stopped working (while xDAX RX channels continued to function).

    I eventually found a workaround: run xDAX inside Terminal

    I’m on Sonoma - below System Preference commands reflect that OS version. Using Mac mini M2 for radio.


    If you would like to give my workaround a try…

    1) On the Dock, bring up the Microphone pane - ie., navigate to System Settings > Privacy & Security > Microphone

    2) Note if Terminal is in the Microphone list (it might not be found at this point).

    3) Launch a Terminal window (e.g., command-space Terminal, or via Finder window in Applications\Utilities).

    4) If Terminal was not previously in the Microphone list, hopefully it will now be there.

    5) Determine if the entry for Terminal is “on” (slider button is to the right). If it isn’t, turn it “on”.

    All the above are one-time setup actions.


    For routine use: launch a Terminal window and enter…

    /Applications/xDAX.app/Contents/MacOS/xDAX


    I employ Terminal's right-click "New Command...", which brings up a "recent commands" list. Makes it easy to launch xDAX under the above's "new way".


    A security-related caveat…
    … I suspect that granting Terminal microphone access allows anything run via Terminal to have access to the “microphone environment”.


    73…

    Mike WA7IJV
  • Many thanks Mike, I will give it a try.

    73, Gordon, ve7on

  • kenb
    kenb Member ✭✭

    i also have this problem after upgrading. from the xDAX log:

    2024-09-11 05:19:02:969 [Info] > DaxPanelViewController, setDaxEnabled() - TX audio stream enabled
    2024-09-11 05:19:03:015 [Warning] > xLib: Unknown Slice token: sample_rate = 24000

    sample rates are set to 48000 according to the Midi app.

    Mike, thanks for the workaround. i'll give it a try. has anyone reported this to rogue…

    73, ken ns7v

  • Mike WA7IJV
    Mike WA7IJV Member ✭✭
    I believe Gordon is in contact with the Loopback vendor.

    I've seen that same diagnostic. As you note, it appears all pieces (digi app, virtual device port speed, etc.) are at the same 48k speed. I've also tried different speeds (which seem to work as well).


    Perhaps this MacOS Console diagnostic may be relevant to the xDAX TX issue:

    Refusing authorization request for service kTCCServiceMicrophone and subject Sub:{de.DL3LSM.xDAX}Resp:{TCCDProcess: identifier=de.DL3LSM.xDAX, pid=83050, auid=502, euid=502, binary_path=/Applications/xDAX.app/Contents/MacOS/xDAX} without NSMicrophoneUsageDescription key

    Unlike other apps listed in my mac’s Microphone pane - FLdigi, WSJT-X, etc. - xDAX isn’t shown. So, we can’t “turn it on” in the MacOS-required manner.

    BTW, I am seeing other potentially worrisome xDAX logging in the Console. Fingers crossed...

    Mike
  • I have been in contact with Rogue Amoeba. Many emails and still no luck. The latest is that they are going to consult their engineering department. I have gone back to ver. 2.3.2 and it works fine. There is something wrong with the new update.

    Gordon, ve7on

  • K3SF
    K3SF Member ✭✭✭

    any update from rogue ameba…i am in the same boat with sequoia and loopback and xdax

    xdax does not show up in privacy /mic

    even when when started via terminal

    paul K3SF

  • Mike WA7IJV
    Mike WA7IJV Member ✭✭

    I updated my older Intel radio mini from Sonoma to Sequoia. Now, xDAX doesn’t run at all (even via Terminal). Ditto for xCAT.

    Mac SmartSDR and dogparkSDR don’t see my Flex, most of the time.

    However - xSDR6000 sees the Flex consistently, and starts OK. But, typically freezes minutes later if I’m screen sharing from another Mac to the Intel mini. Things are better if I instead use a monitor/kb/mouse (greatly reduces network traffic), but still feels fragile.

    xDAX never has shown up in my primary or backup radio Macs’ Microphone list, either. On Sonoma or Sequoia.

    I suspect xDAX was coded (circa 2020) for an earlier set of audio access requirements, and doesn’t make needed calls on the newer MacOS versions - to be recognized as a mic-using app.

    Terminal was already in my Sonoma Microphone list when I first tried the “xDAX in Terminal” method, months ago. Sometime earlier, MacOS probably asked me if Terminal should be added to the list when I ran an audio-using app (e.g., fldigi) from Terminal. And, I said "yes".

    Once Terminal is in the list, I suspect xDAX inherits the mic access.

    Until Sequoia came along…

    Mike


  • K3SF
    K3SF Member ✭✭✭
    edited November 2024

    Hi all

    i too have been having similar issues with xdax and loopback and sequoia…

    on my m1 macbook air ( my test bed computer) i am running macos 15.1 , loopback 2.4.4 and xdax 2.0

    wsjtx receives audio fine from the radio ( xdax) but no transmit audio gets to the radio (xdax)…

    i have not been able to get mic privileges for xdax…that is the real issue

    i verified this by using the following configuration.

    loopback 2.4.4, macssdr 2.9.95, macos 15.1…using the dax and cat function of macssdr

    i am able to run wsjtx just fine…receives and transmit just fine cause macssdr has mic privileges

    as does its dax and cat apps…

    I have sent email to Mario who develop xdax and xcat but have not heard back from him.

    my other thought is to contact Marcus and see if he would make his Dax and Cat

    as stand alone so we can use it directly with wsjtx and my flex 6600m

    if any one here has any other ideas on how to resolve this issue.

    i am sure other would greatly appreciate it too.

    Paul K3SF

  • ChrisAC9KH
    ChrisAC9KH Member ✭✭

    Guys, this problem shouldn't have anything to do with Loopback. The problem is permissions in MacOS for xDAX to access the mic and the app won't appear in the list to enable because the app hasn't been maintained for newer versions of MacOS. And the source code is not available for anybody to fix it.

    But you can add an app manually to the list using the commandline. Before you do this it's probably a good idea to back up your TCC database with:

    cp ~/Library/Application\ Support/com.apple.TCC/TCC.db ~/TCC.db.bak

    Then connect to the datbase server with:

    sqlite3 ~/Library/Application\ Support/com.apple.TCC/TCC.db

    You can list the current apps in the database with:

    select * from access where service = 'kTCCServiceMicrophone' ;

    Take note of the table columns in the database because it's going to be different for older versions of MacOS. But for MacOS 15 Sequoia, for instance, you insert a record into the database with:

    insert into access values ('kTCCServiceMicrophone','de.DL3LSM.xDAX', 0, 2, 2, 1, null, null, null, 'UNUSED', null, 0, 1737919031, null,null,'UNUSED', 0);

    The 1737919031 column is the Unix format for the date in seconds since Unix Epoch. and at the time I'm typing this is the current Unix time. If you don't know what it is you can get the Unix time from this website for that table entry:

    https://www.epochconverter.com

    Now check your Settings → Privacy and Security → Microphone and xDAX should be in the list like so and now your Tx audio will work in xDAX:

  • ChrisAC9KH
    ChrisAC9KH Member ✭✭
    edited January 27

    Duplicate post.

  • Mike WA7IJV
    Mike WA7IJV Member ✭✭

    My normal non-privileged login is denied access to TCC.db. Via Terminal and DB Browser for SQLite.

    Also tried admin login, but it doesn't have access to my login's Library folder.

    Mike WA7IJV

  • ChrisAC9KH
    ChrisAC9KH Member ✭✭
    edited January 28

    If you only have a non-admin account on your Mac then use sudo but you'll need to know the password for the admin login.

    You should be able to navigate to the database file and see who has read-write permissions to it:

  • ChrisAC9KH
    ChrisAC9KH Member ✭✭

    Or if your non-admin account is not in the sudoers file, then use the admin account to make your non-privileged login an admin login. Then log into it and make the database entry, log out and go back to the admin account and switch it back to a non-admin account.

  • K3CDY
    K3CDY Member ✭✭
    edited January 28

    Forgive the naive question but why is anyone using xDAX? I'm running without it, and have all my audio routing perfectly using Loopback.

    I'm running WSJT-X Improved, FLDigi, Software Defined Connectors, and JS8Call, which receive and send streamed audio perfectly c/o Loopback and MacSSDR's built-in DAX.

  • ChrisAC9KH
    ChrisAC9KH Member ✭✭

    Mac SSDR's DAX is not standalone. If, for instance, you want to run SSDR on your iPad while running a digital mode app on your Mac you need xDAX to make the audio connection to it. Or some folks might be using xSDR6000 instead of SSDR, in which case you need xDAX to handle the audio.

  • K3CDY
    K3CDY Member ✭✭

    Thank you Chris. I had never heard of xSDR6000 until now. Sounds intriguing.

  • Mike WA7IJV
    Mike WA7IJV Member ✭✭

    Another xDAX advantage: multiple RX channels (up to your rig's maximum slices limit). That allows running several apps (and/or several instances of same app) at the same time on receive.

    MacSSDR only provides one RX channel.

  • ChrisAC9KH
    ChrisAC9KH Member ✭✭

    Yes, xDAX can handle multiple DAX streams. I use it all the time to run JS8Call on one slice with SSDR's DAX, and WSPR with WSJTx on another slice with xDAX. Just create another virtual audio interface for your second app using xDAX. Many times I'll run the other slice on my iPad Air and xDAX can connect to that, Mac SSDR can't.

    @K3CDY Doug has xSDR6000 on GitHub under his callsign K3TZR. You can either use git clone to clone the repo and build it yourself, or download a pre-built binary from the releases. Doug was working on a new version of it (you'll find it under the SDR6000 repo) but he hasn't had time to work on it recently. xDAX was actually built using Doug's xLib6000 library. xSDR6000 is open-source and it's on GitHub as a Xcode project. You can modify it all you want and build a custom version of it with Xcode.

  • Mike WA7IJV
    Mike WA7IJV Member ✭✭

    Getting back to xDAX-in-mic-list…

    Granted admin to my standard login, and rebooted. But, I was still blocked trying to backup TCC.db.

    Finder Get Info says I have rw on TCC.db (and parent folder com.apple.TCC).

    I don't know the admin password SUDO wants.

    I'd better leave well enough alone. UNIX is not my strong suit.

    xDAX-via-Terminal seems to work for some (me included), but not for others. Just was curious if I could eliminate the Terminal part.

    Thanks - 73...

    Mike WA7IJV

  • K3SF
    K3SF Member ✭✭✭

    hi Chris

    did the fix you showed….worked for me on my macbook (MBA) air M1 with sequoia

    took a few tries on my part…copy /paste mistakes along the way cause mba has such small screen for this stuff ;-O…

    thanks

    Paul K3SF

    ran a quick test on air and all went well…

    will be doing same with mac mini M1

  • K3SF
    K3SF Member ✭✭✭
    edited 12:25PM

    well attempt on mac mini m1 and ran into user privilege…all users have admin privilege

    still not successful on m1 mini ???

    seems system only has privilege to change

    can not add any of admin user to the list

    kinda confused as it went so smoothly when it did on macbook air M1

    Paul K3SF

  • ChrisAC9KH
    ChrisAC9KH Member ✭✭

    @K3SF Paul, that is the wrong file. You are trying to change the one in the root of the file system. The database file you need to change is the one in your user Library, designated by the tilde ~ on Unix systems. Or instead of the tilde you can use the full path from the root of the file system.

    The database file you want to change is ~/Library/Application\ Support/com.apple.TCC/TCC.db

    Note the importance of the tilde in the path.

  • K3SF
    K3SF Member ✭✭✭

    will try again…as i was doing the change on m1 mini by remote login…which maybe keeping me forun using the proper pathname…i have small server farm ( 4 mac mini's of various generations..they dont die)…

    i will bring this one into the shack and add KB, mouse and monitor and login directly…

    thanks for hanging in there with me on this

    on side note…i am trying to have chaptgpt help me reverse engineer xDax…have large portion of code so far

    but

    my **** fingers have caused me to make syntax errors …GRrrrrrrr…

    even when i do cut and paste

    i have reached out to Mario about xDax but have gotten NO response

    and

    even asked Marcus to to consider pulling out his DAX and CAT from macssdr

    as separate apps …maybe making those as 'tools' or add-on parts for macssdr users

    i run 6600M here and take advantage of every bit of capability that i can

    not unusual to have 4 receivers going on here doing different things

    Paul K3SF

  • ChrisAC9KH
    ChrisAC9KH Member ✭✭

    Maybe I should add a further explanation of what we're doing here because this is not a "hack". Since xDAX is not coded to ask for mic permissions we're just adding it manually to the TCC (Transparency, Consent and Control) database using standard database queries at the command line. You can also use a graphical database client like TablePlus or DB Browser but using the command line is simple and quick if you know the commands. You can add any app to the database if you know the app's Bundle Identifier, which can be gotten by looking at the app's package contents Info.plist file. Since I dapple with software development I just happen to know where this stuff is and how to do it.

    So on MacOS, Finder is not set up by default to mess with the stuff that makes your system work. It does not even show your user Library by default. If you are an experienced user you can set up Finder to do that, but using Finder and a graphical database client requires several steps that become complicated, where it's pretty simple at the command line.

    So where this is falling apart is in distinguishing between the root Library and your user Library, and this could be Mike's problem too. If you open your Terminal application and type:

    cd /Library && ls -la

    This will change directory to the root Library and list the ownership and permissions.

    OTOH, if you type:

    cd ~/Library && ls -la

    This will change directory to your user Library and list ownership and permissions. You will see that they are two different things because of the simple addition of the tilde on the second command. Omitting that tilde will cause any further commands to fail unless you su root and Darwin does not have a root user, you must use sudo to interact with things that can break your system. So if you follow my instructions in my previous post, paying very careful attention to the syntax of the commands, it will work. The database table entry for the Unix timestamp is not exceedingly important, the system just uses that for date and time that the table entry was last modified and it may affect its position in the list if you sort a database query by date modified.

    On systems like Mike's where the normal user is non-admin, if an app requests permission to use the mic it is going to normally prompt for an admin password to add it. This is the same thing as sudo at the command line.

    So in summary, again, this is not a "hack". We are simply adding an app to a database that the system uses to determine who can use the mic. We are doing it manually because the app is not coded to ask for it, and the GUI provides no method to do it.

    For the future, Mario never released the source code for xDAX so at this point it is sort of orphaned. He built the application for his own use and put it out there for free for others to enjoy. But he may have moved on to other things and no longer has the time or desire up to update it. Ultimately, I think maybe getting Marcus to make DAX/CAT standalone in Mac SSDR, with the ability to handle more than one audio stream and connect over the network, similar to the Windows SSDR, is probably a better solution. Mac SSDR is superbly done, much cleaner and easier to use interface vs the Windows version IMO. Updating DAX to have the Windows capability to connect to remote devices over the network (like an iPad) would be awesome.

    Hope this helps to understand it better.