[hpsdr] Mac ghpsdr

Jeremy McDermond mcdermj at xenotropic.com
Sat Feb 6 19:34:23 PST 2010


After talking with Bill and playing a bit more, I've decided to at least release my work to the general public.

I have a version ghpsdr v2 in my SVN repository at:

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

Feel free to check it out and see if it works for you.  I make no guarantees.

I'm currently listening to a couple of rag-chewers 80m while watching a movie on Hulu, and writing this e-mail.  There's very minimal snap/crackle/pop.  I actually think that if I can tune the real-time thread priorities a little bit, I might be able to eliminate it.  The real-time thread priorities are based on the number of bus cycles you get out of a total number of bus cycles on the system.  So, I think maybe with some looking at instrumentation and doing some of that evil "math" stuff, I may be able to tune it a little better.

Note that you'll need my OzyUtils-MacOS tools off of my SVN to load the Ozy firmware before you start up ghpsdr.

The changes I've made to the code are the following:

- 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 amount 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.

I've added a Wiki page to provide at least some meager documentation on this stuff.  I'll try to improve the documentation and place some pointers to the Apple Developer documentation for all the tips and tricks that I've implemented.

Let me know if you have any problems, and I'll see if I can do something with them.

--
Jeremy McDermond (NH6Z)
Xenotropic Systems
mcdermj at xenotropic.com






More information about the Hpsdr mailing list