<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
Boy, this brings back some ancient memories...<br><br>Referring to http://www.zapatatelephony.org/linux.html<br><br>"<font style="" face="Verdana">Also, at system startup, <strong>hdparm</strong>
must
be run with the <strong>-c1 -d1 -u1</strong> flags. This enables 32 bit
I/O, DMA, and the
unmaskinterrupt flag. This allows the IDE driver not to interfere with
the tormenta
driver."<br><br>Now, after 11 years, it hasnt changed too much. The "tormenta" driver was renamed the "Zaptel" driver and then renamed the "DAHDI"<br>driver, and people are more likely to be using the SCSI (SATA) driver, but the issue is just as valid.<br><br>Try doing that. I bet that you wont have any more problems with hdparm -t anymore.<br><br>I sure "tormented" many Linux boxes with hdparm -t a long time ago. :-)<br><br>JIM WB6NIL<br><br></font><br>> Date: Sun, 20 Feb 2011 12:53:09 -0500<br>> From: steve@michiganbroadband.com<br>> To: steve@michiganbroadband.com<br>> CC: app_rpt-users@ohnosec.org; yokshs@sbcglobal.net<br>> Subject: Re: [App_rpt-users] Beagleboard and USB URI dongle<br>> <br>> OK, looking back through my old notes I have a note that mentions that the<br>> audio drop occurs *sometimes* while apt_rpt is doing it's HTTP data<br>> reporting to allstarlink..<br>> <br>> This is *still* happening but not all the time or consistently..<br>> But sometimes and very noticeably the audio pops occur at the same time<br>> app_rpt sends it's stats.<br>> <br>> <br>> I did however recently find another test where I can cause the audio dropout<br>> to occur about 90% of the time which is far more consistent than waiting<br>> for app_rpt to do it's stat push.<br>> <br>> By running hdparm -t<br>> <br>> In my case it's:<br>> <br>> hdparm -t /dev/ida/c0d0p1<br>> <br>> Just as the program exits it makes the audio popping..<br>> *almost* every time.<br>> <br>> Oddly ad frustratingly it's *almost* every time..<br>> Not really sure why 10% of the time it doesn't happen..<br>> But be come kind of narrow timing window thing going on here.<br>> But *where*?<br>> <br>> Especially if you wait 5-10 seconds (or more) before running it again.<br>> <br>> <br>> This is the ONLY way in 2 years I've been able to induce the popping<br>> myself from a test.<br>> Otherwise it happens randomly as mentioned previously.<br>> <br>> A couple quick related notes is that the problem does *not* occur<br>> when running hdparm -T instead (buffer speed test)<br>> <br>> Nor when you manually flush the drive cache by running the sync command.<br>> <br>> Other activities that test the hard drive (large file copies etc.) do not<br>> induce the problem.<br>> <br>> That test is on a SCSI RAID5 array server..<br>> Not tried it on a plain jane IDE system yet<br>> <br>> hdparm -t /dev/ida/c0d0p1 (Makes 3-4 definite audio pops in succession on<br>> exit)<br>> <br>> /dev/ida/c0d0p1:<br>> Timing buffered disk reads: 72 MB in 3.06 seconds = 23.56 MB/sec<br>> [root@MBB001 ~]#<br>> [root@MBB001 ~]#<br>> [root@MBB001 ~]#<br>> [root@MBB001 ~]# hdparm -T /dev/ida/c0d0p1<br>> <br>> <br>> <br>> <br>> <br>> /dev/ida/c0d0p1: (no pops EVER)<br>> Timing cached reads: 776 MB in 2.00 seconds = 388.05 MB/sec<br>> <br>> <br>> -Steve<br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> > Hi Chuck..<br>> ><br>> > My box (pretty much a fresh ACID install) does not even have NTPD<br>> > running on it.<br>> ><br>> > What I did try was running the heck out of ntpdate which has absolutely<br>> > no effect whatsoever on the audio as it does it's thing syncing the clock.<br>> ><br>> > I've done a LOT of other 'similar' tests like this over the past year<br>> > trying to find something that influences the behavior or induces it to<br>> > occur.<br>> ><br>> > While I was at it I also ran <hwclock --systohc> just for kicks.<br>> ><br>> > Again about anything I can think of does not cause the issue to surface..<br>> > It just does it on it's own seemingly randomly.<br>> ><br>> > In it's little subtle irritating way :-)<br>> ><br>> > And just for convenience... a video from Nov 14 2009.<br>> ><br>> > Radio Key command listening to PL and the issue. :-)<br>> ><br>> ><br>> > http://www.youtube.com/watch?v=lqYwhtuVLDs<br>> ><br>> ><br>> ><br>> > -Steve<br>> ><br>> ><br>> ><br>> ><br>> ><br>> ><br>> ><br>> ><br>> >> Why not run ntpd and keep your clock in sync all the time instead of<br>> >> once an hour :)<br>> >><br>> >> Jim, K6JWN<br>> >><br>> >> On Thu, Feb 17, 2011 at 01:09:17AM -0600, Chuck Henderson<br>> >> <rpt2@chuck.midlandsnetworking.com> said:<br>> >><br>> >>> When I started using this software I noticed the audio issues in my<br>> >>> test<br>> >>> environment. I tried a dozen different mothertboard/CPU combinations<br>> >>> and 3<br>> >>> different USB fobs. I found that the faster the system the<br>> >>> less noticeable the issues but even a 3.4 GHZ quad core still had the<br>> >>> issues. I experimented with a lot of variables and several things made<br>> >>> some<br>> >>> difference but the single most significant thing that reduced the issue<br>> >>> was stopping ntpd. I now run ntpdate 40 seconds after the hour, every<br>> >>> hour.<br>> >>> This keeps the date and time close enough and greatly reduces the<br>> >>> audio<br>> >>> glitch like sounds that I was noticing. Also I found that when the<br>> >>> system<br>> >>> is not under test and is using real hand held and mobile stations<br>> >>> working<br>> >>> through the repeater that the remaining audio glitch like sounds<br>> >>> are indistinguishable from typical normal radio noise hits. By the<br>> >>> way,<br>> >>> my<br>> >>> final choice for a system board is the D510MO.<br>> >>> While I do not know for sure, I suspect that when ntpd makes tiny<br>> >>> adjustments to the system time, this results in tiny glitches in the<br>> >>> processing in the USB sound system. I am clueless how to track it down<br>> >>> any<br>> >>> further, and do not see any need.<br>> >>> Chuck<br>> >><br>> >> --<br>> >> This message has been scanned for viruses and<br>> >> dangerous content by MailScanner, and is<br>> >> believed to be clean.<br>> >><br>> ><br>> ><br>> > Michigan Broadband Systems Inc.<br>> > "Always Connected"<br>> ><br>> > (734)527-7150<br>> ><br>> > Steve's cellphone: (734)904-1811<br>> ><br>> ><br>> > --<br>> > This message has been scanned for viruses and<br>> > dangerous content by MailScanner, and is<br>> > believed to be clean.<br>> ><br>> <br>> <br>> Michigan Broadband Systems Inc.<br>> "Always Connected"<br>> <br>> (734)527-7150<br>> <br>> Steve's cellphone: (734)904-1811<br>> <br>> <br>> -- <br>> This message has been scanned for viruses and<br>> dangerous content by MailScanner, and is<br>> believed to be clean.<br>> <br>> _______________________________________________<br>> App_rpt-users mailing list<br>> App_rpt-users@ohnosec.org<br>> http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users<br> </body>
</html>