Mac-Ghpsdr

From HPSDRwiki
Revision as of 19:17, 6 February 2010 by NH6Z (Talk | contribs)

Jump to: navigation, search

I have done some modifications to the Ghpsdr2 code such that it runs correctly on the Mac. Note that these changes have only been tested on Snow Leopard on 64-bit Intel. I make no claims about it working on any other platform. To build this version, you will need all of the GTK libraries and such described on the Ghpsdr page.

You can get the source to mac-ghpsdr from SVN. The SVN address is:

https://www.xenotropic.com/ham-svn/mac-ghpsdr

It should be in a complilable state at any particular point in time, but do realize this is my development tree. Again, it is in development, so I don't really know how things work outside of my little sandbox.

How To Compile

You must first compile the DttSP library. Do the following:

cd DttSP
make
cp libDttSP.a ..
cd ..

You can then type a make as normal and run the resulting executable.

Changes Made Against the Linux Version

  • Implemented the USB layer in the native Mac IOKit rather than libusb.
  • Used the Asynchronous USB reads and writes so that the program doesn't wait for writes to happen. This reduces CPU load.
  • Changed the code so that we read 16 "Ozy Block" of 512 bytes per read. This reduces the number of kernel calls we do, and significantly reduces CPU load. 16 seems to be the "sweet spot" because ghpsdr sends 1024 samples at a time to DttSP. 16 "Ozy Blocks" is equivalent to 16 * 63 samples = 1008. This makes it so that a single read is equal to almost a dispatch to DttSP. Empirically this seems to work well as well. If you would like to play, there is a OZY_PACKETS_PER_INPUT_BUFFER macro in ozy_buffers.h that will change the value. Make sure you run a make clean before you rebuild after modifying this file (the dependencies aren't really there in the Makefile yet).
  • Changed the thread priorities such that the callback thread and the thread that empties the read buffer are real-time mach threads. As stated above, the priorities may need to be changed around to make things a little smoother. I may chat with folks during the next TeamSpeak about how to go about thinking about the parameters and maybe see if others have some experience with realtime threads on Windows and such.

--NH6Z 02:13, 7 February 2010 (UTC)