Re: [Gta04-owner] QtMoko audio state work
On Thursday, January 17, 2013 01:37:58, NeilBrown wrote: On Thu, 17 Jan 2013 00:52:57 + Neil Jerram n...@ossau.homelinux.net wrote: The upshot of all that is that I'm now inclined to look more again at the other possible solutions, i.e. gta04-gsm-voice-routing (by Radek) and alsaloop (as used in SHR). The simplicity of gta04-gsm-voice-routing is appealing, but I know from previous experience that it sometimes fails completely. The only problems that I've had with gta04-gsm-voice-routing is when the program that plays the alert sound holds on to the audio port for some reason and thus blocks voice-routing from accessing it. I could probably fix that with certainty by a well-placed 'kill' at the start of voice-routing but I want to work out why it is going wrong first (this is a little program of QtMoko tries to cover that by running pasuspender -- gsm-voice-routing instead of just gsm-voice-routing. I think that means that voice routing only starts once pulseaudio has let go of the sound card. mine ... I think it might be confused by getting signals at bad time - I hate programming with signals). :-) I guess that's also why you don't want to fix the problem by adding a kill. alsaloop in comparison has a drastically different and more complex design. I'm wondering if gta04-gsm-voice-routing is unstable _because_ its design is overly simple, and if something more like alsaloop is fundamentally needed - but I haven't yet worked out even how to start analysing that; any ideas would be most welcome. Also, if we did go with alsaloop, I've no idea yet how we might try to add in echo cancellation. alsaloop is 923 lines while gsm-voice-routing is 673 lines. That isn't drastically more complex. The main value-add seems to be sample-rate matching which doesn't seem to be a big problem in practice (if you need it but don't have it you get occasional clicks. I don't get any clicks). There's also the big difference - at least to me - that alsaloop is select-driven, so reads from capture into alsaloop's buffer happen independently of writes from the buffer to playback. What sort of stability problems do/did you experience with gsm-voice-routing? On several occasions, on receipt of a real incoming call, I've just got a kind of distorted quiet growling noise instead of proper audio from the far end. On the other hand, whenever I'm just testing, the audio almost always works. I wonder if the rest of the phone is using more CPU for a real incoming call than when I'm testing, and if that affects how gsm-voice-routing starts up. Well, you've encouraged me to try more with gsm-voice-routing. I think I need to understand more about _how_ it fails, when it does, and I should be able to discover that by adding more logging. Can I just check: is your gsm-voice-routing code the same as in QtMoko? Many thanks, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] QtMoko audio state work
On Thursday, January 17, 2013 02:50:54 PM Neil Jerram wrote: On several occasions, on receipt of a real incoming call, I've just got a kind of distorted quiet growling noise instead of proper audio from the far end. For me the growling took just one 1 second - IMO it was some old recorded sample and after it finished the program was working normally. The biggest problem was for me the volume - once i raised it, the echo cancelation was not working good. Maybe WebRTC has better algorithms then speex? You can also try to play with alsa record/playback buffer sizes. The smaller the buffers are the smaller will be delay between recording and playing. And last thing that can be tried is speex AEC settings. Thats the line: speex_echo_state_init(256, 8192); Basically the gsm-voice-routing should work like this: rec UMTS - SEND to AEC - play on earpiece rec MIC - cancel echo - play on UMTS cancel echo works by substracting rec MIC - rec UMTS. It would be quite interesting to dump the recored sounds and also the AEC'ed sound to files and open them in some program to see how the sounds are shifted in time and to see how the AEC works. IIRC speex has also another cancelling mode besides speex_echo_cancellation() function. Hmmm maybe i could start playing with it again - after one year i can find something new. Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] QtMoko audio state work
On Thu, 17 Jan 2013 14:43:19 +0100 Radek Polak pson...@seznam.cz wrote: The simplicity of gta04-gsm-voice-routing is appealing, but I know from previous experience that it sometimes fails completely. For me the problem was that some other program had soundcard open and gta04- gsm-voice-routing couldnt open it. If all programs use pulseadio then it can be solved with pasuspender, but i wish that alsa had the same functionality. Then we could get rid of pulseaudio. Maybe something like this could be achieved using alsa plugins. The dmix alsa plugin is intended for this purpose. If it is active, then multiple clients can open the device and the sounds they write get mixed together and played. A problem with this is that dmix imposes a fixed (I think) sample size, which implies a fixed latency which is probably more than the latency we want. gsm-voice-routing is quite latency sensitive, both for quality-of-call and for effectiveness of the echo cancelling. NeilBrown signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] QtMoko audio state work
On Thu, 17 Jan 2013 13:50:54 + Neil Jerram n...@ossau.homelinux.net
wrote:
What sort of stability problems do/did you experience with
gsm-voice-routing?
On several occasions, on receipt of a real incoming call, I've just got a kind
of distorted quiet growling noise
instead of proper audio from the far
end. On the other hand, whenever
I'm just testing, the audio almost
always works. I wonder if the rest of
the phone is using more CPU for a real
incoming call than when I'm testing,
and if that affects how gsm-voice-routing
starts up.
Well, you've encouraged me to try
more with gsm-voice-routing. I think
I need to understand more about _how_
it fails, when it does, and I should be
able to discover that by adding more
logging.
Can I just check: is your gsm-voice-routing
code the same as in QtMoko?
Not exactly :-)
I've just pushed out the code that I'm using to
git://neil.brown.name/gta04-gsm-voice-routing
(master branch).
I thought I'd made more changes than it seems that I have...
Just:
--- a/gsm-voice-routing.c
+++ b/gsm-voice-routing.c
@@ -596,6 +596,11 @@ int main()
open_route_stream_repeated(p0);
open_route_stream_repeated(r0);
+while (route_stream_read(r1))
+ ;
+snd_pcm_start(r0.handle);
+snd_pcm_start(r1.handle);
+
/* Route sound */
while (!terminating) {
NeilBrown
signature.asc
Description: PGP signature
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
