[hpsdr] Mac ghpsdr

[Richard Stasiak]

Hi Jeremy

I was trying to compile your Mac ghpsdr code today and got past  
compiling DttSP.

When running Make on the main library I got a long error output that  
seemed to point at the lack of a gtk library.

Can you recommend which library to use and possibly on how to install  
it.

Thanks for making the your code (and John's) available for the Mac.


Rick ve3mm

On 6-Feb-10, at 10:34 PM, Jeremy McDermond wrote:

> ***** High Performance Software Defined Radio Discussion List *****
>
> 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
>
>
>
> _______________________________________________
> HPSDR Discussion List
> To post msg: hpsdr at openhpsdr.org
> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org
> HPSDR web page: http://openhpsdr.org
> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/
>


 1265577617.0