From: Daniel Phillips <phillips@arcor.de>
To: Mark Spencer <markster@linux-support.net>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: Zaptel Pseudo TDM Bus
Date: Sun, 21 Jul 2002 22:04:06 +0200 [thread overview]
Message-ID: <E17WMw3-0008CC-00@starship> (raw)
In-Reply-To: <Pine.LNX.4.33.0207211359210.25617-100000@hoochie.linux-support.net>
On Sunday 21 July 2002 21:01, Mark Spencer wrote:
> > A random question: is there any reason why Ogg isn't among the codecs?
>
> It wasn't ready when I started. Ogg, like mp3, is generally a very poor
> choice of codec for telephony, and even for the storage of files, unless
> its performance has improved greatly.
I don't know about performance (except for quality: it's said to require
about half the bitrate for the same quality, compared to mp3) however, it
has one killer advantage over mp3: it's patent-free, and hence, royalty-free.
I'd think that would be important for your project.
> On a 900 Mhz Athlon, you can get *hundreds* of simultaneous full-duplex
> GSM full-rate codecs running. Certainly that's an unrealistic expectation
> even for half-duplex ogg or mp3.
But that would be an argument against supporting mp3 as well.
> As for using ogg as an actual telephony
> protocol, its frame size is (or at least was at the time I contacted the
> author) much too long to be practical. Frame sizes for VoIP should be
> around 160 to 240 samples in general.
On a quick reading, this appears to indicate you can easily have what you
want:
http://www.xiph.org/ogg/vorbis/doc/framing.html
Perhaps the last time you looked at Ogg the streaming format had not yet been
completed?
Also, doesn't part of telephony consist of having lots of pre-recorded audio
around, for voice mail etc? Granted, an encoder optimized for music is not
necessarily optimzed for voice. However, would that not be a matter of
tweaking the encoder? As I understand it, the vorbis compression format is
quite general, and in fact, all the recent work that improved the quality so
noticably involved only the encoder.
OK, this isn't a really kernel issue, so... I'll clamp my hams and post it
anyway ;-)
--
Daniel
next prev parent reply other threads:[~2002-07-21 19:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-20 23:25 Mark Spencer
2002-07-21 0:52 ` Daniel Phillips
2002-07-21 18:59 ` Mark Spencer
2002-07-21 20:46 ` Daniel Phillips
2002-07-21 21:00 ` Mark Spencer
2002-07-21 21:39 ` Karim Yaghmour
2002-07-21 23:09 ` Daniel Phillips
2002-07-21 1:27 ` Daniel Phillips
2002-07-21 19:01 ` Mark Spencer
2002-07-21 20:04 ` Daniel Phillips [this message]
2002-07-21 20:49 ` Mark Spencer
2002-07-21 13:14 ` Francois Romieu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E17WMw3-0008CC-00@starship \
--to=phillips@arcor.de \
--cc=linux-kernel@vger.kernel.org \
--cc=markster@linux-support.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®