Re: [codec] #16: Multicast?

["Christian Hoene" <[e-mail]>]

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