Bug 2811

Summary: Google Talk audio doesn't work with if speex has been installed
Product: [Maemo Official Applications] Chat & Call & SMS Reporter: Tuomas Kulve <tuomas>
Component: VoIPAssignee: rtcomm <rtcomm>
Status: CLOSED FIXED QA Contact: internet-call-bugs
Severity: normal    
Priority: Low CC: felipe.contreras, karstenb, maemo, murrayc
Version: 4.0   
Target Milestone: ---   
Hardware: All   
OS: Linux   

Description Tuomas Kulve (reporter) 2008-01-21 10:48:56 UTC 
STEPS TO REPRODUCE THE PROBLEM:

Install ogg-support from:
http://maemo.org/downloads/product/OS2008/ogg/

EXPECTED OUTCOME:

Google Talk Internet calls should work OK. Either the speex shouldn't be
selected at all even if it's installed, or the voip call engine should support
it too.


ACTUAL OUTCOME:

The call is connected but nothing can be heard.

REPRODUCIBILITY:

always

EXTRA SOFTWARE INSTALLED:
ogg-support (speex)

OTHER COMMENTS:

It seems that the Google Talk client finds speex gstreamer codec and for some
reason prefers it. When both call parties have speex installed, it seems to be
selected as the audio codec for the call. However, when the actual call is
being sent it doesn't work. Maybe the voip call encoder/decoder engine refuses
to use speex even though it's selected.

Is there a configuration file relating to this, like the metalayer crawler has?
Comment 1 Tuomas Kulve (reporter) 2008-01-21 10:51:37 UTC 
A workaround, if you don't need speex but want ogg-support:

As root: rm /usr/lib/gstreamer-0.10/libgstspeex.so
Comment 2 Tuomas Kulve (reporter) 2008-01-21 11:00:30 UTC 
Couple missed of notes:

The "steps to reproduce the problem" is missing the actual step, like "make the
call", but maybe that's clear from the expected outcome. And also the callee
has to have the ogg-support installed.

I tried to use tcpdump to get a better idea of the problem but the calls are
mostly encrypted (which is a very good thing), so I mostly guessed the "other
comments" section.
Comment 3 Tuomas Kulve (reporter) 2008-01-22 19:13:40 UTC 
I took a tcpdump from a SIP call and speex really is offered as the first codec
(at least in some calls).
Comment 4 Olivier Crête 2008-03-18 17:12:40 UTC 
Yes, if SPEEX is installed, Farsight will detect it and offer it, but since the
maemo architecture is a bit special, there is no alsasrc/sink.  It may do the
same for theora/vorbis..

We should add the following to /etc/farsight/gstcodecs.conf .. The ogg-support
installer should probably do it.

[audio/SPEEX]
id=-1

[audio/VORBIS]
id=-1

[video/THEORA]
id=-1
Comment 5 Felipe Contreras nokia 2008-03-19 14:25:17 UTC 
Good job tracking the issue.

Tuomas: can you confirm this?

If so, perhaps this bug should be marked as invalid, otherwise please comment.
Comment 6 Tuomas Kulve (reporter) 2008-03-19 14:38:16 UTC 
(In reply to comment #5)
> Good job tracking the issue.
> 
> Tuomas: can you confirm this?

I can try and probably it works as said.

> If so, perhaps this bug should be marked as invalid, otherwise please comment.

I don't still see this as invalid as you claim to support something you
actually don't. I'm hoping your next release will have those -1 lines in the
conf.

There's always a risk of messing something up when you start sed'ing
configuration files automatically from debian postinst scripts.

Maybe this component should again have a conf.d directory in which codec
packages can add their own configs and run some update-farsight-codecs -command
to create the real config file.
Comment 7 Mikhail Zabaluev nokia 2008-03-19 16:38:14 UTC 
I can't see why in principle Farsight cannot manage both types of codecs at the
same time: those encoders/decoders that are also sources/sinks can coexist with
codec pipelines that require the global source/sink for capture and rendering.
The current tablet architecture is freaky, but it's not impossible to meet this
kind of elements on other platforms. IMHO, it shouldn't be a configuration
matter.
Comment 8 Olivier Crête 2008-03-19 17:55:16 UTC 
In practice, changing the source while a pipeline is running is a very nasty
matter. Being able to have only one source/sink running at the same time
(because of the way the DSP works) makes it even nastier.
Comment 9 Mikhail Zabaluev nokia 2008-03-19 18:12:01 UTC 
(In reply to comment #8)
> In practice, changing the source while a pipeline is running is a very nasty
> matter.

Isn't it more about changing the sink if the incoming payloads change from one
type to another? The sending codec can be selected once after the intersection
is negotiated.

> Being able to have only one source/sink running at the same time
> (because of the way the DSP works) makes it even nastier.

I thought the PCM sink can be used simultaneously with "computational" codec
sinks. But anyway, this is no different from the current problem of switching
from one DSP decoder to another.
Comment 10 Mikhail Zabaluev nokia 2008-03-19 18:13:33 UTC 
(In reply to comment #9)
> Isn't it more about changing the sink if the incoming payloads change from one
> type to another? The sending codec can be selected once after the intersection
> is negotiated.

Well, it can be renegotiated later, so this point is moot.
Comment 11 Karsten Bräckelmann 2008-06-03 02:09:31 UTC 
Removing keyword moreinfo as per comment 6 (the second part of it).
Comment 12 Olivier Crête 2008-09-05 02:05:23 UTC 
SPEEX should be disabled by default on diablo (I guess this can be marked as
fixed).
Comment 13 Tuomas Kulve (reporter) 2008-09-05 08:57:27 UTC 
Verifying that it looks like the SIP client doesn't advertise Speex anymore in
Diablo as said in comment #12 and therefore SIP calls should again work even if
speex is installed in both devices.
Comment 14 Mikhail Zabaluev nokia 2008-09-05 09:22:56 UTC 
Thanks, fixed then.
Comment 15 Tuomas Kulve (reporter) 2009-09-26 11:47:04 UTC 
I never got around to testing this again in Diablo since I removed the Speex
from the ogg-support.

I'm verifying this now based on the fact that Fremantle ships with Speex.
Comment 16 Mikhail Zabaluev nokia 2009-10-19 16:26:23 UTC 
Closing the verified bugs.