Please wait...
Something like the Minnesota company Multitech still makes?
http://www.newegg.com/Product/Product.aspx?Item=N82E16825362030
Costly, but seems retro cool for $106. But as copper will disappear in the future, 9600 will probably be the top end of things. I have done 9600 bps over VOIP in the past (not good, but it works).
You would be better served by enslaving your sound card to be an an analog modem to "talk" to the other endpoint that also listens with a sound card "modem". You should be able to adapt that to what ever compression comes in to play in the future to further compress the human voice in to barely audible bits on an ever squeezed pipe :-)
Mine is more like these: https://www.google.com/search?q=MT5634ZBA-USB&oq=MT5634ZBA-USB
And yes, probably expensive, but I picked mine up off a discard pile. :)
The phone service that comes with Verizon FiOS actually is VoIP, even if they don't give the subscriber access to anything other than the POTS ports.
A little USB modem picked up off a discard pile was fun to implement as a Caller ID detector, and maybe sometime in the future I'll configure it to send faxes or something. I wonder if anyone still uses those.
Ha, faxes. Mostly real estate agents, used car sales(people), and other vermin :-) I had a chance to get one of those modems like you picked up off the pile IG, but thought I would just stick with the trusty old Zoom or USR 56K with a usb to serial adapter.
at least over here in germany faxes are still very broad in use with lawyers and courts - to send documents so they arive in time before the postal services deliver the original...
I had to write something for modem not too long ago.
Closed captions still use modems, in spite of the Voip crap going on these days. That is part of the problem with captioning today.
I wonder if there are drivers for the Pantelegraph for Linux :-)
http://en.wikipedia.org/wiki/Pantelegraph
Tue Apr 08 2014 08:32:41 AM EDT from fleeb @ Uncensored
Hmm... I want to see an RFC for it.
April 7th 1969 - RFC #1.
You would need to go to the set of negative RFC's to get anything before that date.
so today I learned fancy things about the glibc malloc implementation:
it only can return the most recently allocated block to the OS.
so if you only have a tiny leak 'tagging' this block, it will remain bound to your process forever.
or - if you only manage to allocate more space before you free that memory (so the next block is requested) it remains forever yours[tm]
However, this isn't just a problem with the glibc implementation. All malloc implementations need to get their memory from *somewhere* -- and that somewhere is obtained by making a call to brk() to set the size of the program's data segment. Obviously the program can't ask for the data segment to be shrunk if there's something in use at the end of it.
I suppose you could use alloca() in some situations to get memory from the stack instead of the heap, but that's got limitations...
Wed Apr 09 2014 06:00:48 PM EDT from dothebart @ Uncensoredwhats your plan to avoid it?
Patch / upgrade, or leave at the old version that does not include heartbeat.
Oh, and password changes and replacement of certs post patch / replace. Plus more firewall rules in case it proves to be a bad patch (and / or recompile without the heartbeat option and deploy packages).