[Gta04-owner] QtMoko v48 sound problems
edorfaus at xepher.net
Sun Oct 28 02:03:38 CEST 2012
I recently got a GTA04 (I think A4), and have put QtMoko v48 on it.
I've run into some problems with the sound - or rather, the lack of it -
and am hoping for some help, and/or that my findings can help someone
fix things (or show me what I've done wrong).
The problem seems to be caused by a combination of several issues.
I've found some workarounds for most of this, but I'm going to summarize
everything anyway, just to have everything in one place, and so
everyone's on the same page.
The initial problem was that I had no sound, whether from media players
or during calls (in either direction).
During calls, I looked at the options, which included radio buttons for
earpiece and speaker - neither of which were selected, and it didn't
help to select either of them.
I did manage to get sound from aplay by using alsamixer to enable some
of the outputs, but using that every time didn't seem like a good
solution - and the ALSA state files would probably reset it anyway.
However, I noticed the headset controls were enabled, and some searching
online gave me a thread (on this very list) where someone had the
problem that the device basically detected a headset despite none being
Somewhere during this, I found a suggestion of installing a v49 qtmoko
kernel, to get some /sys files to look at, so I downloaded the .deb for
that, installed it with dpkg -i, and rebooted. I'm not sure it took
though, since uname -a still says v48, though apt-cache show says 49-1.
That kernel was also supposed to fix an error (with stack trace IIRC)
seen in dmesg, and I've seen that error since (but forgot to save it).
I'll save it if I reproduce it again.
Either way, watching the in7_input file as suggested in  gave me
values around 1111 (yes, that's four ones), which according to NeilBrown
suggests something's funky with my hardware (possibly a short). I think
I also saw values around 29 sometimes, but that might have been without
I did as suggested, removing /dev/input/event4 (and the jack symlink)
and restarting QtMoko, which improved the situation somewhat - media
players could then play sound.
I haven't made this persistent yet (by editing qpe.sh IIRC), but will
probably have to unless we can come up with a better fix.
During calls however, there was still no sound.
Some more searching gave me another workaround - selecting a profile
with no sounds (just vibra), and not using the media player, made the
sound work in calls. However, this comes at the expense of not having
any ring tone, which makes it easy to miss incoming calls and messages,
especially since the vibration doesn't last very long.
The culprit is the mediaserver process, which apparently doesn't release
the sound card quickly enough after playing a sound for alsactl to
restore the gsmearpiecehw.state properly.
I did some testing with lsof here, and found out that after playing the
ringtone, the mediaserver held on to the sound card for about 15 seconds
before releasing it. Using the media player, it held on to the card for
about 25 seconds after selecting pause or stop.
To me, this sounds suspiciously like an optimization to avoid having to
reopen the sound card if someone wants to play another sound soon after
the previous one, that just happens to be very counterproductive in this
I also found out that if you start playing a song in the media player,
then terminate the media player (which seems to be the only way to exit
it, that I've found anyway), the song continues playing in the
background, and then the mediaserver process never releases the sound
card (or at least takes so long to do so that the difference doesn't
matter), even after the song has finished.
Starting the media player back up doesn't reattach to the playing song,
but instead allows me to start playing it again concurrently... which
doesn't work out very well.
All this makes me wonder if, since the mediaserver process likes to hog
the sound card, it would be more practical to make it apply the ALSA
state files itself, instead of calling out to alsactl?
I suppose that would mean duplicating some of its code, to parse and
apply the states, but if that's what's necessary to make it work reliably...
Of course, that depends on the idea that applying the states requires a
connection to the sound card; if what is actually required is that noone
has a connection, that probably wouldn't help much (other than having an
obvious entry point for enforcing that the mediaserver closes its
connection I suppose)...
Hm, maybe it would be easier to have a way of making the mediaserver
close its connection on demand? E.g. a signal (SIGUSR1 maybe?) that
makes it stop whatever it's doing and close the device immediately?
(Or... is that what we have now, except it doesn't work right? I guess I
should take a look at the code before I start handing out random
suggestions like this...)
I remember seeing a suggestion about using PulseAudio - and PA does have
a way of doing that latter suggestion, even provides a CLI tool for
doing it. It is used similarly to sudo: "pasuspender <command>" that
makes PA release the sound card as long as the <command> is running. So,
instead of running "alsactl restore -f <file>" directly, you'd run
"pasuspender -- alsactl restore -f <file>".
(Note that this is not meant as a recommendation for using PA, but just
to show that it does have this functionality, in case that's a factor.)
More information about the Gta04-owner