[Gta04-owner] QtMoko v48 sound problems

[EdorFaus]

Hi,

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 
plugged in.

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 [1] 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 
the evtest.

[1] 
http://lists.goldelico.com/pipermail/gta04-owner/2012-October/003062.html

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 
case.

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.)

-Frode