<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
I really would not be horribly shocked if the SCSI/SDA drivers do something nasty and take too much time<br>and interfere with the proper operation of the Zaptel driver.<br><br>Linux... the great experiment..<br><br>JIM WB6NIL<br><br><br>> Date: Sun, 20 Feb 2011 13:30:43 -0500<br>> Subject: RE: [App_rpt-users] Beagleboard and USB URI dongle<br>> From: steve@michiganbroadband.com<br>> To: telesistant@hotmail.com<br>> CC: steve@michiganbroadband.com; app_rpt-users@ohnosec.org; yokshs@sbcglobal.net<br>> <br>> Certainly does!!<br>> So you also remember distros shipping with all the IDE enhanced stuff turned<br>> off and actually using hdparm on startup to SET some performance options<br>> too eh?<br>> Wow that was a long time ago!<br>> <br>> Anyhow I've not tested on IDE yet and none of those options apply<br>> to the 'ol SCSI system I have up & testing at the moment. :-)<br>> (It won't accept those options).<br>> <br>> But aside from that it looks like I've identified one easy test<br>> that reliably 'interrupts' the usb audio routine and demonstrates<br>> that something is or can punch noticeable holes in it. :-)<br>> <br>> <br>> I've not tested IDE yet (coming soon) :-)<br>> <br>> -Steve<br>> <br>> <br>> <br>> <br>> <br>> <br>> ><br>> > Boy, this brings back some ancient memories...<br>> ><br>> > Referring to http://www.zapatatelephony.org/linux.html<br>> ><br>> > "Also, at system startup, hdparm<br>> > must<br>> > be run with the -c1 -d1 -u1 flags. This enables 32 bit<br>> > I/O, DMA, and the<br>> > unmaskinterrupt flag. This allows the IDE driver not to interfere with<br>> > the tormenta<br>> > driver."<br>> ><br>> > Now, after 11 years, it hasnt changed too much. The "tormenta" driver was<br>> > renamed the "Zaptel" driver and then renamed the "DAHDI"<br>> > driver, and people are more likely to be using the SCSI (SATA) driver, but<br>> > the issue is just as valid.<br>> ><br>> > Try doing that. I bet that you wont have any more problems with hdparm -t<br>> > anymore.<br>> ><br>> > I sure "tormented" many Linux boxes with hdparm -t a long time ago. :-)<br>> ><br>> > JIM WB6NIL<br>> ><br>> ><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<br>> >> 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<br>> >> 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<br>> >> 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<br>> >> 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<br>> >> absolutely<br>> >> > no effect whatsoever on the audio as it does it's thing syncing the<br>> >> 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<br>> >> 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<br>> >> 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<br>> >> the<br>> >> >>> issues. I experimented with a lot of variables and several things<br>> >> made<br>> >> >>> some<br>> >> >>> difference but the single most significant thing that reduced the<br>> >> issue<br>> >> >>> was stopping ntpd. I now run ntpdate 40 seconds after the hour,<br>> >> 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<br>> >> 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>> ><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>> <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> </body>
</html>