(#488) Re: (#484) Speakfreely patches
Speak Freely Forum <[email protected]> Wed, 8 Oct 2003 02:38:48 +0200 (MEST)
| Newsgroups | gmane.comp.audio.speak-freely.general |
|---|---|
| Message-ID | <[email protected]> |
Message posted to the Speak Freely Forum by John H on Wed, 8 Oct 2003 02:38:48 +0200 (MEST). http://www.fourmilab.ch/wb/speak-freely.pl?rev=488 Reply To: (#485) Re: [speak-freely] (#484) Speakfreely patches Author: Thomas Shaddack Date: 2003-10-07 10:35 : Forwarded from the [email protected] : mailing list: : > * I have written : resampling routines to change sampling : frequencies. On _some_ : Could be interesting for handing the voice data : over to a third-party : process. A possibility to output to not only : the soundcard but also eg. : stdout could be beneficial. (I could take a : look at it sometimes.) I don't know. That resampling is just for getting around soundcard problems. The other modification I made which seems more related is logging facility. in that case both sfmike as sfspeaker try to open a connection to a port on the local machine, and then send the compressed audio to that port. A program listening on that port then assembles and queues the packets into talkspurts and writes them to disk. I'm using that to store conversations in gsm format that can later be played by sox etc. It could quite happily write to stdout rather than the disk. : (Another interesting extension I could play : with is a simple control : interface, possibly a listening UDP socket, : that could facilitate simple : interprocess communication - switching : transmitting on/off, later maybe : establishing connection to specified IP - so : allowing running sfmike as a : daemon, etc.) That could be interesting for non-telephony applications. For just running on a remote computer, I'd be more inclined to just run sfmike over ssh. : > I also plan the following: > * Add the : Speex codec. That's for the better : bitrate/quality tradeoff, and : > because it has algorithms to extrapolate : through lost packets. I'm thinking : > both unix and windows versions for this. : > : > * I may have a try at echo-cancellation : and comfort noise - especially as : > speex has algorithms for the former. : That's VERY interesting! I'll post when I have some results. It shouldn't be a hard job to do speex, because the library looks quite easy to use, and much the same as the gsm library. : > If anyone is interested in these patches, : or to try merging them, let me know. : > It seems that the sourceforge projects : aren't really going yet either. : I am, it could be interesting at least to look. : I could try to merge them : with my security-related patches. I'll do a bit of tidy-up and see about posting some patches in a few days. I think I'll split off the resampling from the packet-handling because they are mostly unrelated and I'm not testing the resampling with day to day use. : You may also like to check this: : http://www.sci.fi/~mjkoskin/ There are : some programs there for denoising audio; they : are for wav files, but they : maybe could be rewritten to work on realtime : audio. Could offer further : quality improvement, especially with lower-end : hardware. (My experiences : with audio processing are somewhere between : zero and negligible so can't : be of much help here. :( ) Thanks. Noise isn't a worry with my current communications, so it won't be a high priority for me. Speex has an in-built noise reduction algorithm that I'll probably try out. My main goals are overcoming packet loss and reducing end-to-end delay. * * * To unsubscribe from this mailing list, send E-mail containing the word "unsubscribe" in the message body (*not* as the Subject) to [email protected]