maemo.org Bugzilla – Bug 2811
Google Talk audio doesn't work with if speex has been installed
Last modified: 2009-10-19 16:26:23 UTC
You need to
before you can comment on or make changes to this bug.
STEPS TO REPRODUCE THE PROBLEM:
Install ogg-support from:
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
The call is connected but nothing can be heard.
EXTRA SOFTWARE INSTALLED:
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?
A workaround, if you don't need speex but want ogg-support:
As root: rm /usr/lib/gstreamer-0.10/libgstspeex.so
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
I took a tcpdump from a SIP call and speex really is offered as the first codec
(at least in some calls).
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.
Good job tracking the issue.
Tuomas: can you confirm this?
If so, perhaps this bug should be marked as invalid, otherwise please comment.
(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
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.
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
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.
(In reply to comment #8)
> In practice, changing the source while a pipeline is running is a very nasty
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
> 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.
(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.
Removing keyword moreinfo as per comment 6 (the second part of it).
SPEEX should be disabled by default on diablo (I guess this can be marked as
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.
Thanks, fixed then.
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.
Closing the verified bugs.