Lower audio quality that chan_datacard about asterisk-chan-dongle HOT 26 OPEN

How do you define "much lower"? Any reproducable metrics?
I never tried chan_datacard, but I noticed that the default volume settings of 
chan_dongle result in audio from sip to dongle is very loud, and audio from 
dongle to sip is very faint. (Using K3765 dongle). Didn't bother to tweak 
volume settings yet tho.

Let's say with datacard I had the quality of an ulaw/alaw codec. With
dongle, it's lower than the GSM codec.

Maybe previously the unit registered with 3G (mode 5,4) and now it is 
registered with 2G (mode 3,2)?

With 2G it could never have had ulaw/alaw quality, and I really doubt it would 
do more than GSM when using 3G.

Maybe it's even related to weather conditions and signal reception quality, the 
position of the dongle, the number of active call on the cell tower, possibly 
related to the time of day, etc.

So, that's why I asked if you have any metrics that are... "more objective" 
than your ears ;-)

Believe me, the quality is lower than before. Another user on an
italian forum confirmed also.

Broadcom BCM63xx is big endian ?

Yes, it's Big Endian but we solved that problem (the loud noise). This
time the audio is normal but it has a low quality. It could be due to
low signal ... I'll have to test with a different SIM card.

With chan_datacard (the version before changing to chan_dongle) I had
crystal clear audio on the same Big Endian platform.

Could you provide a link to this italian forum?
Although I don't speak italian (Google Translate probably does), maybe the 
discussion on that forum could be of interest here.

He just said he has this problem. Let me try to find it again.

This is what the guy said:

"Piccola nota: la qualit� audio della conversazione � un po piu bassa
di una normale chiamata GSM: sapete se devo installare qualche codec?"

Your quote is from: http://www.nabuk.org/f/index.php?topic=2909.0

The author also says:
La prova che ho fatto è sta :
1)tramite cellulare con android e client SIP chiamare un cellulare
2)Poi ho richiamato lo stesso cellulare facendo una normale chiamata

And Google translates this to:
The test I did is:
1) via mobile phone with Android and SIP client to call a mobile phone
2) Then I called the phone making a normal call.

Which seems like a very accurate translation.

The author did not describe what call codec was used between Android-SIP and 
Asterisk. Also the author did not say anything about chan_dongle settings, such 
as volume settings.
Furthermore, a GSM-to-GSM call will always have better call quality than a call 
that is routed through a third system, quite probably including transcoding 
from one codec to another. I don't know very much about chan_dongle's internals 
yet, but I wouldn't be surprised if the dongle itself does "transcoding" of the 
GSM audio to 8khz ulaw/alaw, based on the AT^CVOICE response including '8000'. 
Transcoding would result in some quality loss as well.

Also, that comparison was made between asterisk 1.8+chan_dongle and asterisk 
1.6+chan_datacard, so that wouldn't be a fair comparison due to all kinds of 
changed defaults between 1.6 and 1.8.

So, that's why I said I'd love to hear some objective, quantifyable metrics. 
Maybe chan_dongle is indeed worse than chan_datacard, but first there has to be 
a way to define 'worse' ;-)

laster google chan_datacard is same as early chan_dongle...
only names changed

I've used the GSM to GSM call in my test. I suppose the signal was
low. I'll try to test chan_dongle with a different SIM card from a
different provider.

@fpal: yout stataed "it's Big Endian but we solved that problem (the loud 
noise)" in comment 6 above. May I ask how you solved the endianess issue? I am 
asking because I was having that issue on the old chan_datacard too and used 
some brute-force method to "solve" it, and was also facing bad audio quality 
(only in send direction) afterwards:
https://code.google.com/p/datacard/issues/detail?id=84
Has the endianess-issue been solved in chan_dongle? Or what did you do to 
resolve that on your end?
I have not tried chan_dongle yet, as I currently don't have access to my big 
endian box any more, but would be interested to hear whether endianess is also 
still an issue in chan_dongle!

Try on the chan_datacard forum. There is a patch I've posted that
solves the issue. The patch was created by Paul Fertser.

Forgot to tell you, bg_one has already implemented that patch into chan_dongle

Thanks for the info. I now migrated to chan dongle, but still the issue 
persists that I described under the above link for chan_datacard: the voice in 
send direction sounds distorted ("robotic"). I don't think that it is "worse" 
than chan_datacard like the original Issue suggests, but the same quality that 
I had with chan_datacard when applying my own patch. So I am not sure whether 
it is related to endianess or might be something else.
I tried this with an E1750 using current trunk and interconnecting with ISDN 
(using chan_lcr). Will give SIP a shot to see if it is related to the 
interconnect. The same setup using chan_mobile (of which the original 
chan_datacard was a fork?), would have clear voice in both directions (also 
after applying the endianess patch).

[deleted comment]

The sound is better when interacting with SIP instead of ISDN. Strange. So this 
does not seem to be related to chan_dongle directly, or at least not solely. 
Will check my setup. Thanks anyway for the info!

I investigated a little further: I tried several channels in combination with 
chan_dongle, and it seems somewhat related to the frame size/number of samples, 
at least that is the only relationship I found so far.

chan_dongle <-> chan_sip, framesize 320, number of samples 160 (debug output in 
channel.c/channel_write()) -> good audio quality in send direction

chan_dongle <-> chan_lcr (ISDN), framsize 256, number of samples 128 -> 
"robotic" audio in send direction, still comprehensible

chan_dongle <-> chan_mobile, framesize 48, number of samples 24 -> just some 
clicking in send direction, totally uncomprehensible

chan_sip and chan_lcr both use alaw as "outgoing" codec, so they should be very 
similar what their codec chain is concerned when connected to chan_dongle. The 
frame sizes were the only noticable differcence.
Any ideas? Could this be related? I noticed that the debug output in channel.c 
was originally intended for frame sizes <320 bytes only (but the  if-statement 
was commented), are/were smaller sizes maybe regarded as problematic?

I tried the same setup on an x86 (Ubuntu 10.0.4 LTS on an Pentium 3), and the 
issue remains the same: for calls that interconnect chan_dongle with other 
channel types (in my case chan_lcr and chan_mobile), the voice quality in send 
direction (so the voice heard on the mobile that is calling or is being called 
by the dongle) is bad (chan_lcr) or even uncomprehensible (chan_mobile). 
chan_sip and chan_dahdi (also used for ISDN via vzaphfc, so just another driver 
for the same isdn setup that is used with chan_lcr) do not have that problem. 
The only noticable difference is the above mentioned framesize that is less 
than 320 bytes for all channels that show the problem. The unproblematic 
channels all have framesize 320.
Also note that chan_dongle's "father" chan_mobile never has this issue. 
Replacing the Huawei-dongle with a bluetooth-dongle + Mobile phone -combination 
has crystal clear audio always, regardless of the channel type it is talking 
to. 

The issue I observed above seems indeed related to frame sizes <320 bytes. 
Filling the "missing" bytes with silence (frames) obviously does not have the 
desired effect, depending on the frame size (see experiments in post 20), it 
will degrade voice quality up to the point where it becomes totally 
uncomprehensible.
I created a patch (hack...) in channel.c that will not send anything via the 
dongle, until it has gathered 320 (FRAME_SIZE) bytes of audio input. If the 
frame size passed to channel_write() is less then that value, it will place 
that data in a temp buffer and wait for more. The audio quality increases a lot 
doing so, but is still not really great. My approach is probably a bit too 
blunt...
But as said, it is more to be seen as a hack, as I do not fully understand the 
chan_dongle source. E.g. there seem to (have) be(en) some write buffers in pvt 
in the past (for that exact purpose?) that got commented.
Note to original poster/topic: this will probably not increase your audio 
quality, as chan_sip already provides frames of 320 bytes size (as also already 
stated in post 20), this only fixes the horrible audio for other channel types 
that provide frame sizes less than 320 bytes.
Maybe this helps to find a clean solution or to track down the root cause of 
the issue.

I can explain:

dongle want one frame of 160 16bit samples each 20 msec :)
for write operation chan_datacard, chan_dongle use timer with 20 msec intervals.

This mean: when upstream channel try write some frame to device, we just put 
this frame to device write buffer. And actually send to device at next timer 
tick.

If upstream  channel send < 320 bytes, on actual write missing bytes fill with 
0.
If upstream channel send  > 320 bytes, extra bytes will be dropped.

I think we need something like circular buffer.

patch is wrong add wrote w/o understanding timer writes and mix buffer of 
chan_dongle.
you free to try just enable 20 ms jitter buffer for chan_dongle

So, i build test host Linux 32 bit with both chan_datacard rev 191 & 
chan_dongle rev 24

and do something like

module unload chan_dongle.so
module load chan_datacard.so
channel originate Datacard/NAME/MOBILE application Playback some_music


module unload chan_datacard.so
module load chan_dongle.so
channel originate Dongle/NAME/MOBILE application Playback some_music


and listen music on my phone.

I can't hear the difference.

Will try compare voice stream passed to USB and also timings

Thanks for explaining the timer concept, it helped me identfy the problem in my 
setup.
Maybe it helps others: the issue is actually unrelated to chan_dongle itself. 
The problem was that I did not have any timer module loaded in my asterisk, 
what makes chan_dongle resort to "untimed" mode, which results in bad audio 
quality. As pointed out above, the dongle expects data to be delivered every 
50ms.
So if audio quality is bad, check if you have a reliable timer source in your 
asterisk setup. For older asterisks the only source is chan_dahdi/dahdidummy, 
newer asterisks should have res_timing_pthread.so, res_timing_dahdi.so or 
res_timing_timerfd.so module loaded (the latter being recommended under linux 
when you don't have ISDN and hence no real use for dahdi). Also see 
https://wiki.asterisk.org/wiki/display/AST/Timing+Interfaces for more info.