Re: Ringtone volume and latency
On Sat, 2010-01-02 at 12:27 +, Neil Jerram wrote: > 2010/1/2 William Kenworthy : > > > > 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. > > Ah, OK, I didn't realise that. (I don't yet get enough incoming > mobile calls to have a significant sample.) > > Still, the CPU needed to decode Ogg (or another compressed audio > format) could be contributing to that. > > > 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). > > In Debian I use auxlaunch for switching between windows. This is > triggered by the AUX button and so is pretty reliable. Could you use > that (or a similar approach) to solve this focus problem? > Tried to use the power button kill - but it doesnt work. When it happens to gpe-calendar, I am able to ssh in and kill it which gets focus back, but have not had ssh available on an affected call yet - not sure what to kill and keep the tho. > > Another is hearing the > > other end, but they cant hear you - also happens randomly. > > OK. (I haven't experienced this one yet.) > > > 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. > > With both ring and vibe there is a very obvious delay - I'd guess 1 or > 2 seconds - between when the vibe starts and when the ringtone starts. > > As you say, there's a lot going on when a call comes in - another > reason IMO for making the ringtone part as simple as possible at that > time. > > Regards, > Neil True - every bit counts - and another cause of lost calls that happened to me recently - " ... this is a really bad line, I'll hang up and call you later [CLICK!]" :( BillK ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ringtone volume and latency
2010/1/2 William Kenworthy : > > 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. Ah, OK, I didn't realise that. (I don't yet get enough incoming mobile calls to have a significant sample.) Still, the CPU needed to decode Ogg (or another compressed audio format) could be contributing to that. > 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). In Debian I use auxlaunch for switching between windows. This is triggered by the AUX button and so is pretty reliable. Could you use that (or a similar approach) to solve this focus problem? > Another is hearing the > other end, but they cant hear you - also happens randomly. OK. (I haven't experienced this one yet.) > 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. With both ring and vibe there is a very obvious delay - I'd guess 1 or 2 seconds - between when the vibe starts and when the ringtone starts. As you say, there's a lot going on when a call comes in - another reason IMO for making the ringtone part as simple as possible at that time. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ringtone volume and latency
On Sat, 2010-01-02 at 01:24 +, 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 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Ringtone volume and latency
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% real0m12.242s debian-gta02:/usr/share/sounds# time play kayleigh.ogg Duration: 00:00:09.29 Title: Kayleigh real0m10.680s debian-gta02:/usr/share/sounds# time play kayleigh.ogg Duration: 00:00:09.29 Title: Kayleigh real0m10.015s debian-gta02:/usr/share/sounds# time play kayleigh.wav Duration: 00:00:09.29 real0m9.652s debian-gta02:/usr/share/sounds# time play kayleigh.wav Duration: 00:00:09.29 real0m9.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. real0m11.881s debian-gta02:/usr/share/sounds# time aplay kayleigh.wav Playing WAVE 'kayleigh.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo real0m9.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 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
