Re: [codec] #16: Multicast? (USB)

["Roni Even" <[e-mail]>]

Hi,
I think that this is going to a wrong direction.  I already suggested that
since the group will  do one codec we first need to decide on the
applications. The initial request was for a wideband codec for the Internet
and this is the application that should dictate the requirements. We can
look at the other applications in the requirements and charter and continue
with the requirements that are in-line with the original application. 
Other applications are nice to have if they do not add more requirements to
the codec to be defined here. We are talking here on more requirements which
in my understanding are not in the scope of the WG


Roni Even

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Christian Hoene
> Sent: Friday, April 30, 2010 3:23 PM
> To: 'Raymond (Juin-Hwey) Chen'; 'Mikael Abrahamsson'
> Cc: [e-mail]
> Subject: Re: [codec] #16: Multicast?
> 
> Hi,
> 
> I just want to share some insights from the recent development of
> Bluetooth's Hands-Free Profile (HFP) version 1.5, which supports
> wideband speech.  One main requirement were on the frame size of 7.5 ms
> because the Bluetooth MAC protocol support scheduling at
> this interval. Actually, to achieve this they modified SBC to work on
> 15 blocks instead of 4,8,12 or 16 blocks and they decided
> against G.722.
> 
> The lesson to learn is about the importance of MAC protocol. To get a
> efficient, low power, and mobile device you have to consider
> the impact of packet scheduling. If packets are scheduled regular, the
> MAC protocol can work more efficient. The more irregular
> packet arrive, the more expensive a packet transmission gets.
> 
> Actually, you can translate the cost of packet scheduling to bits per
> packet. Depending on the wireless technology, it might vary
> substantially. The worst case is 802.11b at 11 Mbps at long preamble -
> then, you can add about 1300 bytes to every packet just for
> physical headers and MAC scheduling. However, more modern technologies
> like LTE and IEEE 802.11n are much more efficient in terms of
> per packet overhead.
> 
> 
> If you ask me, one important usage scenario is over wireless links
> supporting low-power mobile devices. If we ignore this scenario
> it will be a judge mistake:
> a) Battery powered mobile devices must be energy efficient to reduce
> the size of the batteries. Also, they should not demand to many
> computational resources, otherwise they would consume to much energy.
> b) Wireless IP access is also in scope because many devices get
> Internet access LTE, WLAN, Wimax, UMTS, etc.
> 
> 
> Bluetooth headsets are somewhat a special case. Actually, they are two
> cases:
> 1) Headphones (A2DP): For me it is not clear whether supporting the
> Internet CODEC on top of A2DP (which is - by the way - already
> possible according to Bluetooth spec A2DP V1.2) or using the Internet
> CODEC till the Bluetooth AP and transcoding to SBC is more
> efficient, cost effect, or energy saving.
> 2) Mic (HFP): Here is the scheduling of 3.75 or 7.5ms might be an
> important requirement that the Internet CODEC cannot fulfill
> always because it must adapt its parameters to the Internet
> transmission path not just to the Bluetooth link.
> 
> Thus, I would recommend to write a liaison statement to Bluetooth AVT
> group and ask whether they would have interest to include the
> Internet CODEC into a future version of A2DP. Definitely, this must not
> happen soon because the they can do is only if the Internet
> CODEC is finishing. Supporting HFP might be more difficult than A2DP
> because of the very tough requirements on efficiency.
> 
> With best regards,
> 
>  Christian
> 
> ---------------------------------------------------------------
> Dr.-Ing. Christian Hoene
> Interactive Communication Systems (ICS), University of Tübingen
> Sand 13, 72076 Tübingen, Germany, Phone [phone]
> http://www.net.uni-tuebingen.de/
> 
> 
> >-----Original Message-----
> >From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Raymond (Juin-Hwey) Chen
> >Sent: Monday, April 26, 2010 11:02 PM
> >To: Mikael Abrahamsson
> >Cc: [e-mail]
> >Subject: Re: [codec] #16: Multicast?
> >
> >Hi Mikael,
> >
> >Thanks for sharing your experience using a BT headset for Skype calls.
> I think part of the quality
> >degradation that you experienced was due to the reduction of the audio
> bandwidth to narrowband (8 kHz
> >sampling, 3.4 kHz bandwidth), and another part of the degradation was
> due to the audible coding noise
> >of the CVSD codec, a 40-year-old coding technology first proposed in
> 1970.
> >
> >If a high-quality, low-complexity, wider bandwidth IETF codec mode can
> be implemented in Skype and the
> >Bluetooth headset to avoid the CVSD transcoding (together with
> wideband upgrade of the transducers and
> >audio path in the BT headset, of course), then not only will you get
> much better speech quality in
> >your Skype calls than what you have experienced, but also you will get
> a lower latency.  This is
> >because transcoding between the Skype codec and CVSD not only
> accumulates the coding distortion of the
> >two codecs, but also accumulates the coding delays.  Although CVSD is
> a sample-by-sample codec, BT
> >headsets still transmit the CVSD bit-stream in 3.75 ms or 7.5 ms
> packets, and they can potentially add
> >a one-way delay up to 20 ~ 25 ms through the Bluetooth headset (the
> exact delay depends on the
> >implementation).
> >
> >While we were discussing whether a 5 ms packet size can even be
> considered, for many years Bluetooth
> >headsets have been using an even smaller 3.75 ms packet size.
> >
> >Best Regards,
> >
> >Raymond
> >
> >-----Original Message-----
> >From: Mikael Abrahamsson [mailto:[e-mail]]
> >Sent: Sunday, April 25, 2010 1:06 AM
> >To: Raymond (Juin-Hwey) Chen
> >Cc: Koen Vos; [e-mail]
> >Subject: Re: [codec] #16: Multicast?
> >
> >On Sat, 24 Apr 2010, Raymond (Juin-Hwey) Chen wrote:
> >
> >> (7) Already a lot of people are used to using Bluetooth headsets to
> make
> >> phone calls today.  If they have a choice, many of these people will
> >> also want to use Bluetooth headsets to make Internet phone calls,
> not
> >> only through computers, but also through smart phones connected to
> WiFi
> >> or cellular networks.  As more and more states and countries pass
> laws
> >> to ban the use of cell phones that are not in hands-free mode while
> >> driving, the number of Bluetooth headset users will only increase
> with
> >> time, and many of them will want to make Internet-based phone calls.
> >
> >I purchased a BT headset with the anticipation of using it with my
> >computer to make Skype calls. I tried it, but the sound quality when
> doing
> >bidirectional audio (whatever that mode is called) is not good enough,
> it
> >worsens the "skype IP" call quality. I agree that the use case is
> >interesting, but as long as BT sound quality is what it is, it's
> really
> >only the "low end" type  sound quality we're talking about.
> >
> >But yes, I make skype IP calls with my Nokia N900 using BT sometimes,
> so
> >the use case example is definitely valid.
> >
> >--
> >Mikael Abrahamsson    email: [e-mail]
> >
> >
> >_______________________________________________
> >codec mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/codec
> 
> _______________________________________________
> codec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/codec