(#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]