[PeterGV]

Originally Posted by smason

Looks good so far. Small, self-contained, nicely done!

Thanks! Much appreciated.

Originally Posted by smason

Many GRE 500/600 users stopped using com ports a while ago. Any chance of supporting the newer USB drivers?

Actually, the newer USB drivers still create a virtual COM port. It's just that Win500 (for example) is smart enough to enumerate the various com ports and "know" which one is associated with the GRE scanner. I'm not sure how Don does this, to be honest, but the only ways that *I* know how to do it are a lot of work... and I'm not really sure what's to be gained. Is there some reason it'shard for the average GRE user to find out the COM port number that corresponds with their scanner's connection? (that's a serious question, not a rhetorical one, in case there's any doubt).

Originally Posted by smason

Also, any way to eliminate the 7-10 second buffer/delay?

Short answer: No, it's part of the deliberate design of ScannerCast. If enough people think this is a terrible idea, I could be convinced to change it -- if not in V1.0 then in V2.0.

Long answer -- Probably a lot longer than you want: ScannerCast buffers the audio data to account for network issues in sending the data to a client. As ScannerCast is forwarding data to a client (either a player or to Icecast) if the network connection drops or delays a message, the buffer allows ScannerCast to continue processing audio while the network connection gets straightened out. This buffering avoid audio glitches -- I *hate* audio glitches in a scanner feed even more than I hate the delay.

The only time the buffering is probably not necessary is when ScannerCast is talking to a client that's directly attached to the local network (LAN). In that case, the chance of a message being dropped or delayed is VERY small (and ScannerCast deliberately sizes its messages to fit in a single LAN message packet). I could probably be persuaded quite easily to add special-case handling for LAN clients listening directly to ScannerCast (not over the Internet and not via Icecast).

The total amount of buffering that's applied is a function of ScannerCast, Icecast (if you're forwarding to Icecast), and the player. Winamp, for example, by default tried to buffer A LOT of data. So even if ScannerCast where to do no buffering, Winamp would (by default) still buffer incoming data.

Thanks for trying ScannerCast and providing feedback. Hope you take the time to tell me more about the COM port issue, as well as explain how problematic the buffering issue is for you and in what situations you'd like to see the buffer delay eliminated.

Peter
K1PGV