qtmoko keyboard focus enhancement
hi, in case someone finds this useful as well: to make the keys in qtmoko keyboard more distinguishable I changed the background to a checkboard like one: alternating between style=fill:#00;fill-opacity:0.76862745;stroke:none / and style=fill:#2d2d2d;fill-opacity:0.76862745;stroke:none / I would have uploaded the german ones I am using on the openmoko wiki, but due to the excessive spam I guess one cannot edit anything anymore... example images are on scaplinux: http://scap.linuxtogo.org/ best regards robin ps in case you are interested please let me know and I mail them to you directly. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko keyboard focus enhancement
I would suggest to reduce the opacity too (maybe to 0.5), I keep having to show and hide the keyboard when in the Terminal app. -- bye, pabs http://wiki.openmoko.org/wiki/User:PaulWise ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Another open hardware mod experiment: RFID-tag/Reader board for the Freerunner, Nanonote (?) and Beagleboard
Hi, I would like to buy The Freerunner RFID but boards not on sale. Does anyone have an extra? http://www.handheld-linux.com/wiki.php?page=RFID%20Board Dr. H. Nikolaus Schaller писал 2011-04-11 11:23: Dear all, besides the GTA04 and the Freerunner Navigation Board, we have been working behind the scenes on a new hardware mod, originally for the Openmoko Freerunner. It is a RFID Antenna, RFID Tag (M24LR64) and a RFID Reader (TRF7960) board. For 13 MHz (ISO14443, ISO15693). The project is still in its beginnings, but the hardware is designed and first samples have been built and appear to work (at least as far as we could test them). And, a first U-Boot based driver running on a BeagleBoard has shown that the RFID reader chip responds and sends interrupts. The tag chip also works and has been tested with an external USB based reader stick. The boards have solder points so that it should be possible to interface to different SoC and boards, e.g. BeagleBoard, Nanonote, OpenPandora... The minimum wiring is that it nedds 3.3V power, 3 SPI wires and a INT line to a GPIO. If power should be controlled or the SoC has 1.8V I/O, more wires are needed. For documentation and details I have uploaded some material to this page: http://wiki.openmoko.org/wiki/Freerunner_RFID_Board Schematics and board layout are available in EAGLE format. Now, what can you do with it? I don't know but would be happy to hear about ideas... We have the idea to sell these complete boards at 79 EUR (which is approx. half the price of a TI eval board), if you are interested in experimenting with this technology. Nikolaus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko audio state work
On Thursday, January 17, 2013 01:52:57 AM Neil Jerram wrote: (In general, for some reason, it appears that the floating point code in Pulseaudio and its dependencies doesn't run any better on armhf than it does on armel.) Hi Neil, do you have also armhf compiled kernel? I had armel kernel + armhf rootfs and it was even slower then pure armel. Btw i am using armhf for a few weeks now and i think i could make a release - just few apps are missing. Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko audio state work
On Thursday, January 17, 2013 01:52:57 AM Neil Jerram wrote: (As usual, for the sake of avoiding any possible negative marketing, I should point out that the main problems here are A3-specific. I hope, and believe to be the case, that phone calls are already reliable on A4.) Yes, A4 works 100% reliably for me now in last few months, but i have just a few calls... With Neil Brown's helpful input, I've reviewed and improved my understanding of all the ALSA state files and controls. This was prompted specifically by the PhoneHeadset state not working (because it was completely wrong) but more generally it bothers me that we use such an over-general system as ALSA state files when there are really only a handful (in fact, 7 switches and 1 volume control) of independent things that we ever need to change when moving between audio states. Also it has bothered me that we don't have a uniform and persistent way of changing overall volume. I've now reimplemented the GTA04 neoaudioplugin.cpp code so that it moves between audio states by changing those 7 switches, instead of using ALSA state files, and that seems to work well (including for PhoneHeadset, subject to A3 software routing trouble). Nice, imo that's the way how it should work. Alsa states were easiest solution - that's why i used it. Your code could work much better. One detail, which is nice but slightly worrying, is that I used to always to get a very audible click about 1s before, e.g., hearing the new message arrival sound; and with the reimplementation I no longer get that click. I _think_ the explanation for that was using pasuspender, and that I no longer get it because I no longer need to use pasuspender pasuspender will still have to be used on A4 when switching to earpiece, because you cant switch if some other program has sound card open. - but it's slightly worrying in case that's wrong, and in particular in case it's because I'm leaving some circuit on more than before, and hence drawing more current. (I haven't seen any evidence for drawing extra current.) Maybe it can be measured during suspend. 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. 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 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: QtMoko audio state work
On Thursday, January 17, 2013 12:49:04, Radek Polak wrote: On Thursday, January 17, 2013 01:52:57 AM Neil Jerram wrote: (In general, for some reason, it appears that the floating point code in Pulseaudio and its dependencies doesn't run any better on armhf than it does on armel.) Hi Neil, do you have also armhf compiled kernel? I had armel kernel + armhf rootfs and it was even slower then pure armel. Ah, interesting. After I managed to build QtMoko for armhf, I installed it in the experimental wheezy/armhf rootfs that you released a few months ago. So it depends what the kernel in that rootfs was. Btw i am using armhf for a few weeks now and i think i could make a release - just few apps are missing. Nice! I am looking forward to that. 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
