[Gta04-owner] QtMoko audio state work

Neil Jerram neil at ossau.homelinux.net
Thu Jan 17 14:50:54 CET 2013


On Thursday, January 17, 2013 01:37:58, NeilBrown wrote:
> On Thu, 17 Jan 2013 00:52:57 +0000 Neil Jerram <neil at ossau.homelinux.net>
> wrote:
> 
> 
> > The upshot of all that is that I'm now inclined to look more again at
> > the other possible solutions, i.e. gta04-gsm-voice-routing (by Radek)
> > and alsaloop (as used in SHR).  The simplicity of
> > gta04-gsm-voice-routing is appealing, but I know from previous
> > experience that it sometimes fails completely.
> 
> The only problems that I've had with gta04-gsm-voice-routing is when the
> program that plays the alert sound holds on to the audio port for some reason
> and thus blocks voice-routing from accessing it.   I could probably fix that
> with certainty by a well-placed 'kill' at the start of voice-routing but I
> want to work out why it is going wrong first (this is a little program of

QtMoko tries to cover that by running
"pasuspender -- gsm-voice-routing"
instead of just "gsm-voice-routing".  I
think that means that voice routing only
starts once pulseaudio has let go of
the sound card.

> mine ... I think it might be confused by getting signals at bad time - I hate
> programming with signals).

:-)  I guess that's also why you don't
want to fix the problem by adding a "kill".


> >                                                 alsaloop in comparison
> > has a drastically different and more complex design.  I'm wondering if
> > gta04-gsm-voice-routing is unstable _because_ its design is overly
> > simple, and if something more like alsaloop is fundamentally needed -
> > but I haven't yet worked out even how to start analysing that; any ideas
> > would be most welcome.  Also, if we did go with alsaloop, I've no idea
> > yet how we might try to add in echo cancellation.
> 
> alsaloop is 923 lines while gsm-voice-routing is 673 lines. That isn't
> drastically more complex.
> The main value-add seems to be sample-rate matching which doesn't seem to be
> a big problem in practice (if you  need  it but don't have it you get
> occasional clicks.  I don't get any clicks).

There's also the big difference - at least
to me - that alsaloop is select-driven,
so reads from capture into alsaloop's buffer happen independently of writes from the buffer to playback.

> 
> What sort of stability problems do/did you experience with gsm-voice-routing?

On several occasions, on receipt of a real incoming call, I've just got a kind
of distorted quiet growling noise
instead of proper audio from the far
end.  On the other hand, whenever
I'm just testing, the audio almost
always works.  I wonder if the rest of
the phone is using more CPU for a real
incoming call than when I'm testing,
and if that affects how gsm-voice-routing
starts up.

Well, you've encouraged me to try
more with gsm-voice-routing.  I think
I need to understand more about _how_
it fails, when it does, and I should be
able to discover that by adding more
logging.

Can I just check: is your gsm-voice-routing
code the same as in QtMoko?

Many thanks,
    Neil


More information about the community mailing list