Re: [Gta04-owner] QtMoko audio state work
On Thu, 17 Jan 2013 13:50:54 + Neil Jerram 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
Re: [Gta04-owner] QtMoko audio state work
On Thu, 17 Jan 2013 14:43:19 +0100 Radek Polak 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 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 Thursday, January 17, 2013 01:37:58, NeilBrown wrote: > On Thu, 17 Jan 2013 00:52:57 + Neil Jerram > 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