Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm not sure this would really work. I mean, remember the modem sounds from the 80s? Could you really tell what was going on based on the sound alone other than the difference between connecting/transmitting/disconnecting?


Differences in handshake sounds would give you some idea of the negotiated speed as others mentioned, but also a good idea of if the handshake was going to succeed. Sometimes you'd get a bad modem or bad line and the handshake would sound wrong and try several times and either not connect or connect at a very low bitrate; cutting that off early was useful.

Of course, in a single line household, sometimes you'd catch the line in use, and the speaker would confirm that vs no dialtone error. Ocassionally, you might also get glare --- picking up an incomming call before it rings, and listening in might help recover from that as well.

Speaker on while connected could be useful for monitoring for connection disturbances (and maybe forcing a lower speed on a reconnect) or call waiting beeps, but was usually too low signal to bother. Also, I had a phone that would click/chirp on call waiting even when on hook which was a lot more actionable.


I could tell a successful handshake from a bad one. After the handshake, it would only signal data transmission, so I always activated the sounds only for the handshake

Earlier with my tape based computer I could tell what program was loading by the sound, and if it had an error.


I could tell from the sounds of the connection if it had negotiated the max 56k or something lower. Of course I could always see it in the connection properties later on, but I could tell just from the initial sounds.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: