[hpsdr] distorted audio from ghpsdr3

[Ken N9VV]

Dave, Rick, others,
John Melton is on a business trip to Turkey and then Switzerland.
He commented to me that ALL THE dspserver AUDIO tries to smash it's
way out the USB port to the D/A converter back on the Mercury board. 
Hence there will be many times when local multiple receivers yield 
distorted, halted, or stuttering audio.  John promised to "work on this" 
when he returns.

Dave McQuate noticed this immediately with his wonderful port of the 
server and receiver to Windoze this week. He commented that you may set 
the audio of one channel to zero to quiet that channel while listening 
to another.  A demonstration video of Dave's work is on my webpage 
showing that action:

<URL: http://www.n9vv.com/Images/WA8YWQ-WindowsXP-2010-07-02.mp4
 >

Any Java programmers are welcome to jump in to help :-)

Here is his info for ghpsdr3:
----------------------------
ghpsdr by default sends the audio stream back to the server to be played 
out through Mercury.  There are command line options to use the local 
audio on the machine your are running on.
 > >
 > >     --local-audio [0|1]
 > >         0 disables local-audio (default)
 > >         1 enables local-audio (default output device is /dev/dsp)
 > >
 > >     --audio-device<dev>
 > >         sets the output device for local audio
 > >
 > >     --port-audio [0|1]
 > >         0 disables portaudio [default]
 > >         1 enables portaudio (output to the default portaudio device)
 > >
 > > I need to work on the portaudio some more to allow selection of 
output device.  Note that if both local-audio and port-audio are enabled 
local-audio takes precedence.
-------------------------------------------
Happy 4th
73 de Ken N9VV


On 7/4/2010 2:39 PM, Dave Larsen wrote:
> ***** High Performance Software Defined Radio Discussion List *****
>
> Rick and Dave --
>
> I had the same issue on my power supply with the same solution all is
> working fine on my quad core linux.  On the PC (2.6 mHz p4) if I add
> more that on receiver running on the PC, I get distortion as well.
>
>     Dave, KV0S
>
> On Sun, 2010-07-04 at 10:58 -0400, Richard Stasiak wrote:
>> ***** High Performance Software Defined Radio Discussion List *****
>>
>> GM Dave
>>
>> I shorted out FU2 (5V regulator) fuse on LPU and all is now well on
>> the hardware front.  No more sudden darkness on the LED's on the HPSDR
>> boards.
>>
>> Have ghpsdr3-windows server and 3 instances of dspserver running on
>> the shack computer (XP 32 bit, 3.2 Mhz. P4).  CPU running at ~70%.
>>
>> I am listening to four receivers in my living room on a MacBook Pro
>> running four instances of jmonitor in OSX 10.6.2. Connected on a
>> wireless network.  It has been stable for the past hour.
>>
>> Once I loaded the second instance of dspserver on my XP machine the
>> audio on the first monitor became distorted.  The audio continues to
>> be distorted on all instances of jmonitor with four receivers running.
>>
>> Should I decrease the sampling rates to 48 khz. to reduce the load on
>> the XP machine?
>>
>> Thanks to you Dave, John G0ORX, Bruce W1BW, Kirk KD7IRS and all of the
>> HPSDR community who have helped, for all of your hard work on this
>> code.  It is really neat to be able to play with 4 RX's at the same
>> time, especially remotely.
>>
>> 73
>>
>> Rick ve3mm
>>
>>
>> On 4-Jul-10, at 4:50 AM, David McQuate wrote:
>>
>>> ***** High Performance Software Defined Radio Discussion List *****
>>>
>>> Yes, Mercury 3.0 does draw significantly more current.  Ozy 18 +
>>> Mercury 3.0 draws about 1.43 amps from the 5V supply.   Looks like
>>> users of the LPU will need to replace the resettable fuse with a
>>> higher current fuse, or jumper across it.
>>>
>>> I see I omitted the file msecsleep.exe from the LoadMercuryFirmware
>>> folder.  Without the required waits,  re-programming of Ozy as a
>>> Byte-Blaster fails, and quartus_pgm doesn't find a USB Blaster.
>>>
>>> I've added that file to the LoadMercuryFirmware folder on the SVN.
>>> 73,
>>> Dave
>>> wa8ywq
>>>
>>> Richard Stasiak wrote:
>>>> Hi Dave and Dave
>>>>
>>>> Thanks for the heads up on the drive designation.  I should have
>>>> picked that one up myself.
>>>>
>>>> Anyway there is still something missing in that directory for
>>>> updating the Mercury FPGA.  I'm not sure what it is.  The update
>>>> still crashed, this time looking for a hardware cable (?).
>>>>
>>>> I was able to get the FPGA loaded by moving your revised update
>>>> batch file and the two mercury4receiver files into Phil's Update
>>>> blaster directory and running the update from there.
>>>>
>>>> With the code loaded I now have another issue, hardware this time.
>>>> The radio is shutting down just after I start the first receiver.
>>>> I haven't started troubleshooting yet, but I suspect the thermal
>>>> fuse in the LPU is not happy.  The new Mercury code must be drawing
>>>> a lot more current in the FPGA.  I will check it out tomorrow.
>>>>
>>>> 73
>>>>
>>>> Rick ve3mm
>>>>>>
>>>>>>
>>>>> _______________________________________________

 1278273958.0