QtMoko audio state work
neil at ossau.homelinux.net
Sat Dec 1 18:15:04 CET 2012
Radek Polak <psonek2 at seznam.cz> writes:
> Yup it looks ok, will test it later but it's alreaady pulled in my git.
Given that, I think it's worth me writing a bit more about where/how my
work is going, and there's one bugfix below that you should cherry-pick:
please look for "While doing that I noticed a bug". Apart from that
bugfix I don't want to make any assumptions about what time you have to
consider this, so please feel free to leave the rest of this hanging for
now. But if you do have time and thoughts I'm sure those would be
useful, and in any case it's helpful for me to lay out my thoughts.
Firstly, I've just pushed some more commits to
https://github.com/neiljerram/qtmoko/commits/nj. These are mostly NOT
suitable for your Git master, so please don't pull them, but they may
help show what I'm doing.
First, my previous set of commits _didn't_ make audio in calls any more
reliable. My initial tests were just lucky, and in the days after that
I had some calls with no audio, the same as before my cleanups. (In
fact that was as expected, because the 'cleanups' didn't really fix
Then I looked for a while at the gta04-gsm-voice-routing code.
- this code often works - giving clear audio - but sometimes fails
catastrophically and gives no audio at all
- it seems to fail more often when an incoming call causes the phone to
wake up from suspend.
My guess is that there is an instability in that code which is more
likely to strike when other things on the phone are using CPU - such as
just after waking from suspend. Perhaps it could something like this:
- CPU load causes gta04-gsm-voice-routing to be slow to read the capture
devices, so they report overruns
- that may cause the code to loop round and try reading those devices
again - which now blocks until time has passed to allow more data to
- when the code eventually gets to the playback devices, too much time
has passed, so they report underrun and don't actually play any data
Then I looked at the alsaloop code and my first impression there was how
much more complex it is... Putting everything together, my feeling is
that this (loopback) is trickier than it looks to get right, and that
gta04-gsm-voice-routing sometimes fails because it doesn't cover all the
So then I looked at pulseaudio, found Neil Brown's old suggestion,
upgraded to the testing version, and eventually stumbled across the
resampler method change that makes that work (per other email). I've
now integrated that in my code:
I then had to make another change to /etc/pulse/daemon.conf:
-; realtime-scheduling = yes
+ realtime-scheduling = no
to avoid pulseaudio being killed by the kernel just after starting the
loopback. I guess this is the same basic problem as SHR had with
and ideally the fix would be in pulseaudio to initially spin more
slowly. But the realtime-scheduling change works too and doesn't impact
general media playback too badly (for my taste).
But after that, the integrated pulseaudio in-call audio routing seems to
work. Of course I'll be more confident about it if I can have a week of
it working every time...
While doing that I noticed a bug in my previous "Rework ALSA state /
QAudioState handling" commit: it will call gsmVoiceStart() and
gsmVoiceStop() even for A4 devices. That's fixed by
so that's one commit that you _should_ cherry-pick.
Next what I'd like to do is to make everything louder! There are 3
things that aren't loud enough at the moment:
a) the ringtone
b) the in-call audio that I hear from the other person
c) the in-call audio that the other person hears from me.
(b) and (c) depend on good echo cancellation, and I'm hoping
pulseaudio's module-echo-cancel will do that for me. I think I can test
that, without needing lots of phone calls, simply by playing something
(from file) through the earpiece or speaker and simultaneously recording
from the microphone. If that works well, we can then just increase all
the volumes in the state files.
(BTW I think that the Speex echo cancellation in gta04-gsm-voice-routing
was less effective because of the playback buffer being 4 times the
frame size. This means that when the code sends frame X to ALSA for
playback, frame X doesn't actually start playing until 3 cycles later.
Therefore we can't immediately use frame X to cancel echo in the
microphone sound that we're capturing _now_. I wonder if there was a
time when the code had buffer size = frame size, and the buffer size was
Finally, if all of the above works, we can look at whether it all
_still_ works with the squeeze version of pulseaudio.
Hopefully eventually the software audio routing can be good enough for
A3 audio quality to be on a par with A4.
More information about the community