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 log in before you can comment on or make changes to this bug.
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?
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 comments" section.
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. [audio/SPEEX] id=-1 [audio/VORBIS] id=-1 [video/THEORA] id=-1
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 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.
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.
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 > 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.
(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 fixed).
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.