[Gta04-owner] QtMoko audio state work

NeilBrown neilb at suse.de
Tue Jan 29 01:17:23 CET 2013


On Sun, 27 Jan 2013 23:45:08 +0000 Neil Jerram <neil at ossau.homelinux.net>
wrote:

> Neil Jerram <neil at ossau.homelinux.net> writes:
> 
> > I'm pretty sure I saw some voice routing problems on a few occasions
> > even with pasuspender.
> >
> > However, since moving back to gta04-gsm-voice-routing, and adding Neil
> > Brown's change to start the 2 capture streams at the same time, I've had
> > a few successful calls and no problems.  For the moment, therefore,
> > things are all working for me.
> 
> I had an unsuccessful call this evening; it was an incoming one.  The
> gsm-voice-routing log for it is below; I plan to analyse this more
> myself to see if there's a repeating pattern of overruns and underruns,
> but thought it worth posting in case someone else sees and understands
> the pattern first.
> 
> I've also made some minor patches to gta04-gsm-voice-routing and have
> attached those here.  Of course it's possible that it could be one of
> those that is the problem...

They look fairly harmless.

> 
> Thanks in advance for any insight!

You get an over-run on the second loop!

So with all the buffers empty, what happen is:

 - read from mic - should wait 32ms
 - read from modem - should return instantly (we already waited the required
                     32ms)
 - write to earpiece - buffer was empty, so no delay
 - write to modem - no delay
 - read from mic - should wait 32ms
 - read from modem - reports an overrun, so buffer must have filled, so must
           be more than 128ms (full buffer) + 32ms (already read) from when
           we started recording (snd_pcm_start).  i.e. 160ms since that first
           'read from mic'.

The 'writes' are very unlikely to have blocked, so it must have been the
reads.  They are allowed to block, for some reason they block too long.

The only thing I can think of is that you have some plugin in place which
causes a larger buffer to be used.  So the first 'read from mic' actually
waits more than 160ms and gets a big buffer.  The subsequent calls all work
directly with buffers and don't block at all.  Then the second
read-from-modem happened too late (because it didn't have a big buffer).

Do you have anything in /etc/asound or /root/.asoundrc ??

Maybe use "hw:0,0" instead of "default".  That should ensure no pluggins are
happening (though I won't promise).

NeilBrown
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: not available
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20130129/7a74e756/attachment.bin>


More information about the Gta04-owner mailing list