Ringtone volume and latency

[William Kenworthy]

On Sat, 2010-01-02 at 01:24 +0000, Neil Jerram wrote:
> In the survey thread, a couple of responses mentioned missing calls
> because of ringtone problems - which I take to be either volume too
> low, or too much latency, or both.  Here are some thoughts on that.
> 
> 1) In case this isn't already well known...  FSO actually does nothing
> at all with the "volume" setting that you can set in SHR settings, or
> Paroli, or in general via the preferences interface.  The only
> relevant code is:
> 
> oeventsd/fso_actions.py:        self.audio_action = AudioAction(
> self.sound_path, self.loop, self.length ) if self.volume != 0 else
> None
> 
> In other words, all non-zero volume values are equivalent.
> 
> 2) I tried to measure startup latency by using `time', for various
> ways of playing a 9.3s Ogg clip and an equivalent .wav file:
> 
> =========================
> debian-gta02:/usr/share/sounds# time mplayer kayleigh.ogg
> A:   9.0 (08.9) of 9.3 (09.2) 40.1%
> real	0m12.242s
> 
> debian-gta02:/usr/share/sounds# time play kayleigh.ogg
>   Duration: 00:00:09.29  Title: Kayleigh
> real	0m10.680s
> 
> debian-gta02:/usr/share/sounds# time play kayleigh.ogg
>   Duration: 00:00:09.29  Title: Kayleigh
> real	0m10.015s
> 
> debian-gta02:/usr/share/sounds# time play kayleigh.wav
>   Duration: 00:00:09.29
> real	0m9.652s
> 
> debian-gta02:/usr/share/sounds# time play kayleigh.wav
>   Duration: 00:00:09.29
> real	0m9.951s
> 
> debian-gta02:/usr/share/sounds# time gst-launch filesrc
> location=/usr/share/sounds/kayleigh.ogg ! oggdemux ! vorbisdec !
> audioconvert ! alsasink
> Execution ended after 9384127000 ns.
> real	0m11.881s
> 
> debian-gta02:/usr/share/sounds# time aplay kayleigh.wav
> Playing WAVE 'kayleigh.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
> real	0m9.709s
> =========================
> 
> There's nothing conclusive here, because I didn't repeat the tests
> enough times yet; but it looks like there's an additional latency of
> at least 0.5-1s associated with playing an .ogg instead of a .wav, and
> rather more than that with gst-launch.
> 
> This and the volume issue suggest to me that it would be better for
> FSO only to handle plain audio data, and to play it (i.e. when an
> incoming call or message comes) using the most lowlevel method (such
> as aplay).  An external settings application could handle conversion
> from the user's sound file to .wav, and as part of that could allow
> the user to adjust the volume and preview the ringtone.
> 
> Comments?  Is there a reason why the complexity (and latency) of
> handling multiple sound formats should be _inside_ FSO?
> 
> Regards,
>         Neil
> 

Just a couple of thoughts - missing calls is rarely to do with volume
and not hearing the ring (I have changed the standard tones though), and
more to do with crashes.  One of the most annoying is using tangogps
full screen (or any other app full screen) and a call comes in the top
screen can (not always) lose focus and you cant do anything except pull
the battery (doesnt recognise finger/stylus).  Another is hearing the
other end, but they cant hear you - also happens randomly.

There is a lot going on when a call comes in so its not only audio
player latency but enabling the audio path, setting up alsa, handling
the call itself, starting the caller application, ...  And in amongst
that it has to play the audio as well.  Currently this isnt too bad for
me when I set ring only (no vibe) and use the debugfs hack.

shr-u most versions, current shr-t.

BillK