[App_rpt-users] Beagleboard and USB URI dongle

[Steve Gladden]

OK, looking back through my old notes I have a note that mentions that the
audio drop occurs *sometimes* while apt_rpt is doing it's HTTP data
reporting to allstarlink..

This is *still* happening but not all the time or consistently..
 But sometimes and very noticeably the audio pops occur at the same time
app_rpt sends it's stats.


I did however recently find another test where I can cause the audio dropout
to occur about 90% of the time which is far more consistent than waiting
for app_rpt to do it's stat push.

By running hdparm -t

In my case it's:

hdparm -t /dev/ida/c0d0p1

Just as the program exits it makes the audio popping..
*almost* every time.

Oddly ad frustratingly it's *almost* every time..
Not really sure why 10% of the time it doesn't happen..
But be come kind of narrow timing window thing going on here.
But *where*?

Especially if you wait 5-10 seconds (or more) before running it again.


This is the ONLY way in 2 years I've been able to induce the popping
myself from a test.
Otherwise it happens randomly as mentioned previously.

A couple quick related notes is that the problem does *not* occur
when running hdparm -T instead (buffer speed test)

Nor when you manually flush the drive cache by running the sync command.

Other activities that test the hard drive (large file copies etc.) do not
induce the problem.

That test is on a SCSI RAID5 array server..
Not tried it on a plain jane IDE system yet

hdparm -t /dev/ida/c0d0p1 (Makes 3-4 definite audio pops in succession on
exit)

/dev/ida/c0d0p1:
 Timing buffered disk reads:   72 MB in  3.06 seconds =  23.56 MB/sec
[root at MBB001 ~]#
[root at MBB001 ~]#
[root at MBB001 ~]#
[root at MBB001 ~]# hdparm -T /dev/ida/c0d0p1





/dev/ida/c0d0p1: (no pops EVER)
 Timing cached reads:   776 MB in  2.00 seconds = 388.05 MB/sec


-Steve



















> Hi Chuck..
>
> My box (pretty much a fresh ACID install) does not even have NTPD
> running on it.
>
> What I did try was running the heck out of ntpdate which has absolutely
> no effect whatsoever on the audio as it does it's thing syncing the clock.
>
> I've done a LOT of other 'similar' tests like this over the past year
> trying to find something that influences the behavior or induces it to
> occur.
>
> While I was at it I also ran <hwclock --systohc> just for kicks.
>
> Again about anything I can think of does not cause the issue to surface..
> It just does it on it's own seemingly randomly.
>
> In it's little subtle irritating way :-)
>
> And just for convenience... a video from Nov 14 2009.
>
> Radio Key command listening to PL and the issue. :-)
>
>
> http://www.youtube.com/watch?v=lqYwhtuVLDs
>
>
>
> -Steve
>
>
>
>
>
>
>
>
>> Why not run ntpd and keep your clock in sync all the time instead of
>> once an hour :)
>>
>> Jim, K6JWN
>>
>> On Thu, Feb 17, 2011 at 01:09:17AM -0600, Chuck Henderson
>> <rpt2 at chuck.midlandsnetworking.com> said:
>>
>>> When I started using this software I noticed the audio issues in my
>>> test
>>> environment.  I tried a dozen different mothertboard/CPU combinations
>>> and 3
>>> different USB fobs.  I found that the faster the system the
>>> less noticeable the issues but even a 3.4 GHZ quad core still had the
>>> issues.  I experimented with a lot of variables and several things made
>>> some
>>> difference but the single most significant thing that reduced the issue
>>> was stopping ntpd.  I now run ntpdate 40 seconds after the hour, every
>>> hour.
>>>  This keeps the date and time close enough and greatly reduces the
>>> audio
>>> glitch like sounds that I was noticing.  Also I found that when the
>>> system
>>> is not under test and is using real hand held and mobile stations
>>> working
>>> through the repeater that the remaining audio glitch like sounds
>>> are indistinguishable from typical normal radio noise hits.  By the
>>> way,
>>> my
>>> final choice for a system board is the D510MO.
>>> While I do not know for sure, I suspect that when ntpd makes tiny
>>> adjustments to the system time, this results in tiny glitches in the
>>> processing in the USB sound system.  I am clueless how to track it down
>>> any
>>> further, and do not see any need.
>>> Chuck
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>
>
>
> Michigan Broadband Systems Inc.
> "Always Connected"
>
> (734)527-7150
>
> Steve's cellphone: (734)904-1811
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>


Michigan Broadband Systems Inc.
"Always Connected"

(734)527-7150

Steve's cellphone: (734)904-1811


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.