Guest ejtagle Posted August 2, 2012 Report Share Posted August 2, 2012 (edited) just tested them and just like the libs from the 4.1.1 OTA for wingray they fail on the framebuffer. it looks like the FB that we (gtab) are using is way diff than what wingray is using. I/ServiceManager( 862): Waiting for service SurfaceFlinger... I/ServiceManager( 862): Waiting for service SurfaceFlinger... I/ServiceManager( 862): Waiting for service SurfaceFlinger... I/SurfaceFlinger( 883): SurfaceFlinger is starting I/SurfaceFlinger( 883): SurfaceFlinger's main thread ready to run. Initializing graphics H/W... E/gralloc ( 883): Can't set nvmap fd: Not a typewriter E/FramebufferNativeWindow( 883): couldn't open framebuffer HAL (Not a typewriter) E/SurfaceFlinger( 883): Display subsystem failed to initialize. check logs. exiting... I/ServiceManager( 97): service 'sensorservice' died I/ServiceManager( 97): service 'power' died I/ServiceManager( 97): service 'entropy' died D/AndroidRuntime( 885): D/AndroidRuntime( 885): >>>>>> AndroidRuntime START com.android.internal.os.ZygoteInit <<<<<< D/AndroidRuntime( 885): CheckJNI is OFF The problem Xoom has is that they are using a completely outdated kernel, and associated outdated framebuffer... And so, outdated proprietary libs... Unfortunately, i was expecting that... edit1: I'll check if something can be rescued from those libs... Edited August 2, 2012 by ejtagle Link to comment Share on other sites More sharing options...
Guest plastikman187 Posted August 2, 2012 Report Share Posted August 2, 2012 (edited) The problem Xoom has is that they are using a completely outdated kernel, and associated outdated framebuffer... And so, outdated proprietary libs... Unfortunately, i was expecting that... Thanks for looking. I noticed that the fb.c was totally different AND it looks like its from 2010 :/...Im not sure it is even worth forward porting their FB just for the "new" libs... Edited August 2, 2012 by plastikman187 Link to comment Share on other sites More sharing options...
Guest ejtagle Posted August 2, 2012 Report Share Posted August 2, 2012 Thanks for looking. I noticed that the fb.c was totally different AND it looks like its from 2010 :/...Im not sure it is even worth forward porting their FB just for the "new" libs... It's not worth the time porting it... I think our libs are already much better... The only thing we could try to use, is the audio decoding, but, again, probably we are better using the ICS libs rather than those old libs Xoom seems to use... Link to comment Share on other sites More sharing options...
Guest plastikman187 Posted August 2, 2012 Report Share Posted August 2, 2012 Well, i found the problem with google voice... Seems it refuses to accept sample rates different from the one that it specifies when starting to digitize sound (8khz). AudioFlinger has a built in resampler, but it is unable to convert from 44.1khz to 8khz, The solution was to implement a very basic resampler that downconverts the 44.1khz to 11.025khz. Then audioflinger will do the rest, downconverting to 8khz. Of course, this is only done for 8khz sampling. Any program trying to get 44.1khz will get it. Hi ejtagle, Can you help to explain to me how to down convert from 48khz to 8khz? The mic on the gtab (smba1002) stops recording at ~9 seconds (possibly muted?) and i am curious if it is because we are using a modified lib from you but at 48khz. I am asking this because i cannot get my device to go to 44.1khz to validate that the 48khz -> 8khz is the cause. this same issue happens to us on ICS. Thanks, plastikman Link to comment Share on other sites More sharing options...
Guest Scanno Posted August 2, 2012 Report Share Posted August 2, 2012 (edited) You are not using the hw accelerated libraries. The key is this part of the log: E/SoftAVC ( 105): Decoder failed: -2 E/OMXCodec( 105): [OMX.google.h264.decoder] ERROR(0x80001001, -1007) I/SoftAAC2( 105): Reconfiguring decoder: 44100 Hz, 2 channels E/MediaPlayer( 1144): error (1, -2147483648) E/MediaPlayer( 1144): Error (1,-2147483648) ... I/OMXCodec( 105): [OMX.google.h264.decoder] AVC profile = 100 (High), level = 31 I/OMXCodec( 105): [OMX.google.h264.decoder] video dimensions are 320 x 240 I/OMXCodec( 105): [OMX.google.h264.decoder] Crop rect is 320 x 240 @ (0, 0) ... When video playback is using hw accelerated decoding, instead of OMX.google.h264.decoder (the software decoder), you should get OMX.nvidia.h264.decoder. Also SoftAAC is a software audio decoder, but tegra supports hw decoding of audio... Please, check that the patches i posted are really compiled into the framework, As an aid to identify this kind of problems, I am attaching 2 scripts: chkall.sh scans all libraries at the current directory and lists all unresolved functions for each one (unresolved functions are functions that are required to be defined in another library to be able to load and use the the current one). You should get NO unresolved functions for any of the nvidia libraries. chkimports.sh does the same as the above but for the specified library. My suggestion is to run it in the /out/product/target/system/lib (the folder where the aosp build puts all the compiled libs). If you get errors in libnvomx*.so, you can be sure the framework patch is not compiled in, and you can also be sure you will get no hw accelerated video/audio decoding... BTW, you will probably need to adjust the path to aosp in both scripts... Hope it helps Eduardo Eduardo, Thanks for the scripts. I ran the chkimports in system/lib, but i did not get any errors. So i guess the framework patch is in place... I do get errors in some libs, but not in the libnvomx*.so. Attached the output of chkall.sh.chkall.txt Edited August 2, 2012 by Scanno Link to comment Share on other sites More sharing options...
Guest ejtagle Posted August 3, 2012 Report Share Posted August 3, 2012 Eduardo, Thanks for the scripts. I ran the chkimports in system/lib, but i did not get any errors. So i guess the framework patch is in place... I do get errors in some libs, but not in the libnvomx*.so. Attached the output of chkall.sh. The log is "normal" ... no problems on the important nvidia libs. You should get hw acceleration ... Check dmesg for out of memory condifions... ;) Link to comment Share on other sites More sharing options...
Guest ejtagle Posted August 3, 2012 Report Share Posted August 3, 2012 Hi ejtagle, Can you help to explain to me how to down convert from 48khz to 8khz? The mic on the gtab (smba1002) stops recording at ~9 seconds (possibly muted?) and i am curious if it is because we are using a modified lib from you but at 48khz. I am asking this because i cannot get my device to go to 44.1khz to validate that the 48khz -> 8khz is the cause. this same issue happens to us on ICS. Thanks, plastikman Depends on the kernel version you are using... 3.1.10 nvidia allow us to set arbitrary SAmpling rates, but with the restriction that recording and playback , if done simultaneously, must be at the same sampling rate and number of channels. When implementing the audio_hw.c android driver, i chose to use a fixed sampling rate and number of channels, and let audioflinger handle downconversion (sample rate conversion)... But, audioflinger sampling rate converter has the limitation that it is unable to downsample to less than half the hw sampling rate.,, That is why, on my latest audio_hw.c, i have implemented a power by 2 sampling rate converter in sw. The idea is that the audio_hw,c downsamples to a sampling rate higher or equal to the requested one, but always less than doubling the sw required sampling rate... Then audioflinger will handle the remaining of the downsampling... Link to comment Share on other sites More sharing options...
Guest Borkata Posted August 3, 2012 Report Share Posted August 3, 2012 Depends on the kernel version you are using... 3.1.10 nvidia allow us to set arbitrary SAmpling rates, but with the restriction that recording and playback , if done simultaneously, must be at the same sampling rate and number of channels. When implementing the audio_hw.c android driver, i chose to use a fixed sampling rate and number of channels, and let audioflinger handle downconversion (sample rate conversion)... But, audioflinger sampling rate converter has the limitation that it is unable to downsample to less than half the hw sampling rate.,, That is why, on my latest audio_hw.c, i have implemented a power by 2 sampling rate converter in sw. The idea is that the audio_hw,c downsamples to a sampling rate higher or equal to the requested one, but always less than doubling the sw required sampling rate... Then audioflinger will handle the remaining of the downsampling... I have updated to your latest audio_hw for our Adam tablet and mic pause problem still occurs, so its probably not the android lib not down-sampling, but kernel drivers related. Also recording + playback is ok. Problem occurs when only recording is active. Link to comment Share on other sites More sharing options...
Guest ejtagle Posted August 3, 2012 Report Share Posted August 3, 2012 (edited) I have updated to your latest audio_hw for our Adam tablet and mic pause problem still occurs, so its probably not the android lib not down-sampling, but kernel drivers related. Also recording + playback is ok. Problem occurs when only recording is active. Strange... maybe dma underrun ? ... Or the audio clock that is being turned off as soon as the audio recording start sound stops... I have a 3.1.1 kernel working for Shuttle, and another one working (not fully, unfortunately) for the p10an10... In none of those devices, i have seen such freezes ... you should really try to move forward to 3.1.1 ... porting drivers from 2.6.39 to 3.1.1 requires nearly no effort, except USB... and, the p10an10 USB config probably is the same as Adam (the p10n10 has 2 usb ports, one of them is fixed to host, and the other is fixed to device... Edited August 3, 2012 by ejtagle Link to comment Share on other sites More sharing options...
Guest fosser2 Posted August 3, 2012 Report Share Posted August 3, 2012 (edited) Strange... maybe dma underrun ? ... Or the audio clock that is being turned off as soon as the audio recording start sound stops... I have a 3.1.1 kernel working for Shuttle, and another one working (not fully, unfortunately) for the p10an10... In none of those devices, i have seen such freezes ... you should really try to move forward to 3.1.1 ... porting drivers from 2.6.39 to 3.1.1 requires nearly no effort, except USB... and, the p10an10 USB config probably is the same as Adam (the p10n10 has 2 usb ports, one of them is fixed to host, and the other is fixed to device... I have been working on our 3.1 port. We got usb working and all but the touchscreen fails on boot. The driver loads but it is not getting any data back. First look shows the driver is working but something is hindering the data... I was hoping it would be something that could be easily fowarded from .39. https://github.com/f...3.1.10-rel-15r7 Borkata: you will be in the same boat once you get the 3.1 running on the adam. The AT168 driver is the same between both devices. Edited August 3, 2012 by fosser2 Link to comment Share on other sites More sharing options...
Guest ejtagle Posted August 3, 2012 Report Share Posted August 3, 2012 I have been working on our 3.1 port. We got usb working and all but the touchscreen fails on boot. The driver loads but it is not getting any data back. First look shows the driver is working but something is hindering the data... I was hoping it would be something that could be easily fowarded from .39. https://github.com/f...3.1.10-rel-15r7 Borkata: you will be in the same boat once you get the 3.1 running on the adam. The AT168 driver is the same between both devices. I just copied the shuttle touchscreen driver from the .39 to the 3.1 kernel... Check i2c bus initialization , copy it from ventana (or harmny), depends the from where your device design is based on.. Check the pinmux table (i used the same as the .39 for my devices), check the clock table (you must avoid initializing clocks that are already managed by the 3.1 kernel... check ventana clocks or harmony clocks for the exact subset, and don't init clocks that the kernel is now managing (but in .39 was not)... for example, on my device, i have removed nearly all clock initializations, otherwise, i have problems...) ... Link to comment Share on other sites More sharing options...
Guest ejtagle Posted August 4, 2012 Report Share Posted August 4, 2012 BTW, I found the problem with the GPS that crashes the system while it turns off... There was a race condition in libgps. Attached a new version that should solve that problemlibgps.rar Link to comment Share on other sites More sharing options...
Guest brucelee666 Posted August 4, 2012 Report Share Posted August 4, 2012 BTW, I found the problem with the GPS that crashes the system while it turns off... There was a race condition in libgps. Attached a new version that should solve that problem Eduardo, I don't have built in gps or external gps but I can confirm that using new lib switching gps satellites on and off no longer results in a reboot of tablet. Link to comment Share on other sites More sharing options...
Guest fosser2 Posted August 4, 2012 Report Share Posted August 4, 2012 (edited) ejtagle, I am just looking through your clock file right now. What exactly does the #if 0 do. I'm trying to figure out when/where you define it. Also in the above post you said you define minimal clocks in the 3.1 kernel. Does this mean you do not define the #if 0 and just use the tegra_clk_init_table at the bottom of the clock file? Thanks! -fosser2 Nvm: guess it just ignores everything w/in that ifdef Edited August 4, 2012 by fosser2 Link to comment Share on other sites More sharing options...
Guest ejtagle Posted August 4, 2012 Report Share Posted August 4, 2012 ejtagle, I am just looking through your clock file right now. What exactly does the #if 0 do. I'm trying to figure out when/where you define it. Also in the above post you said you define minimal clocks in the 3.1 kernel. Does this mean you do not define the #if 0 and just use the tegra_clk_init_table at the bottom of the clock file? Thanks! -fosser2 Nvm: guess it just ignores everything w/in that ifdef in C . the # flags the following instruction as a preprocessor instruction. It means conditional compilation. Here, #if 0 means "if false", so, everything withing the #if 0 and the #else is skipped, not included in the source code to be compiled.... Link to comment Share on other sites More sharing options...
Guest Scanno Posted August 5, 2012 Report Share Posted August 5, 2012 Eduardo, Seems that I am still not able to get the video working. Have to find out what the differences are between your builds and mine. I has used the libs you linked to but no diferences. In dmesg I can also not see strange things. Regarding the huawei rill I have it almost working, but ran into the same problem Cass and I had on ics. The modem is recognized, sees the APN, but cannot get a PPP connection. Link to comment Share on other sites More sharing options...
Guest ejtagle Posted August 5, 2012 Report Share Posted August 5, 2012 - Instead of doing what the readme says, do the following: - Add to uevent.harmony.rc the following line: /dev/ttyUSB* 0777 radio system You should not need to add to init.rc the ril-daemon lines, as JB already adds them for you: Use the rild included in AOSP, do not use an older one. To use it, just add to full_shuttle.mk PRODUCT_PACKAGES += rild after the initial PRODUCT_PACKAGES := \ -Instead of manually adding to build.prop, add to device.mk ADDITIONAL_DEFAULT_PROPERTIES += keyguard.no_require_sim=true ADDITIONAL_DEFAULT_PROPERTIES += rild.libpath=/system/lib/libhuaweigeneric-ril.so ADDITIONAL_DEFAULT_PROPERTIES += rild.libargs=-d /dev/ttyUSB2 -v /dev/ttyUSB1 ADDITIONAL_DEFAULT_PROPERTIES += rild.ppp.tty=/dev/ttyUSB0 ADDITIONAL_DEFAULT_PROPERTIES += ro.pad.features.modem=true -Make sure pppd is set suid root. The problem is that pppd otherwise has no right to create a ppp link... -Compile ppp into the kernel, not as a module (the rild does not know how to insmod it, so it doesn't) -Make sure pppd is at /system/bin ,,, Use the one supplied with AOSP... Perhaps you will also have to add it to the build, if not already present -The huawei ril uses the following command to establish a ppp connection /system/bin/pppd /dev/ttyUSB0 call gprs This means you should have /etc/ppp/peers/gprs as the configuration of pppd... Knowing the command line being used to invoke pppd should allow to debug the connection process, as you can call it yourself :) Regards, Eduardo Link to comment Share on other sites More sharing options...
Guest Scanno Posted August 5, 2012 Report Share Posted August 5, 2012 - Instead of doing what the readme says, do the following: - Add to uevent.harmony.rc the following line: /dev/ttyUSB* 0777 radio system You should not need to add to init.rc the ril-daemon lines, as JB already adds them for you: Use the rild included in AOSP, do not use an older one. To use it, just add to full_shuttle.mk PRODUCT_PACKAGES += rild after the initial PRODUCT_PACKAGES := \ -Instead of manually adding to build.prop, add to device.mk ADDITIONAL_DEFAULT_PROPERTIES += keyguard.no_require_sim=true ADDITIONAL_DEFAULT_PROPERTIES += rild.libpath=/system/lib/libhuaweigeneric-ril.so ADDITIONAL_DEFAULT_PROPERTIES += rild.libargs=-d /dev/ttyUSB2 -v /dev/ttyUSB1 ADDITIONAL_DEFAULT_PROPERTIES += rild.ppp.tty=/dev/ttyUSB0 ADDITIONAL_DEFAULT_PROPERTIES += ro.pad.features.modem=true -Make sure pppd is set suid root. The problem is that pppd otherwise has no right to create a ppp link... -Compile ppp into the kernel, not as a module (the rild does not know how to insmod it, so it doesn't) -Make sure pppd is at /system/bin ,,, Use the one supplied with AOSP... Perhaps you will also have to add it to the build, if not already present -The huawei ril uses the following command to establish a ppp connection /system/bin/pppd /dev/ttyUSB0 call gprs This means you should have /etc/ppp/peers/gprs as the configuration of pppd... Knowing the command line being used to invoke pppd should allow to debug the connection process, as you can call it yourself :) Regards, Eduardo Thans for the reply. I got the video working now. Regarding 3G... rild and pppd are the ones that are compiled by the AOSP build process. PPP is compiled into the kernel (always was according to the config file). Attatched the radio logcat if you want to have a look. Somehow also the apn list is not shown. At least i got the video working :-)logcat_radio.txt Link to comment Share on other sites More sharing options...
Guest ejtagle Posted August 5, 2012 Report Share Posted August 5, 2012 (edited) Thans for the reply. I got the video working now. Regarding 3G... rild and pppd are the ones that are compiled by the AOSP build process. PPP is compiled into the kernel (always was according to the config file). Attatched the radio logcat if you want to have a look. Somehow also the apn list is not shown. At least i got the video working :-) The last time we got problems with the APN list, it was caused by (our trial to use) an incorrect version apn list version... I will check that and post later Great news about video hw acceleration :D edit1: BTW, I have heard about the space limitations we have. We can repartition the NAND device if needed... I think that using Link2sd, the data partition size is really not a big problem... We could reduce it a bit, and expand a bit the system partition, to make google cards work... How much extra space would be needed in system ? ;) edit2: Lately, i've been reading about compressed filesystems, specifically about this: http://bisqwit.iki.fi/source/cromfs.html ... Pretty interesting stuff... ;) Edited August 5, 2012 by ejtagle Link to comment Share on other sites More sharing options...
Guest Scanno Posted August 5, 2012 Report Share Posted August 5, 2012 (edited) The last time we got problems with the APN list, it was caused by (our trial to use) an incorrect version apn list version... I will check that and post later Great news about video hw acceleration :D edit1: BTW, I have heard about the space limitations we have. We can repartition the NAND device if needed... I think that using Link2sd, the data partition size is really not a big problem... We could reduce it a bit, and expand a bit the system partition, to make google cards work... How much extra space would be needed in system ? ;) Personally i do not think we have a space problem on /system. The JellyBean GApps has a lot of data in /usr for en_US, probally related to Google Now. I have not included that in the rom i have published. Right now, with the better compression, we have 14 MiB free on /system, including the GApps, but without the en_US data in /usr. I am using the dutch language to test, and that data is not present in /usr... So i am guessing it is additional data. Link2SD is not working for 100%, because when it is putting the dalvik cache on the SD card, it gets the wrong permissions, resulting in the App not able to access the dalvik cache and crashing... Edited August 5, 2012 by Scanno Link to comment Share on other sites More sharing options...
Guest ejtagle Posted August 5, 2012 Report Share Posted August 5, 2012 Just for reference, i did some small tests... /system compressed with squashfs [gzip] : 147MB /system compressed with squashfs [lzma2] : 134MB /system compressed with cromfs [lzma2,block=4k] : 129MB Gains are not so huge in compression ratio, but if needed, we could use it... Regarding link2sd, maybe we could patch it to fix it, or create a little script that runs at startup and fixes those permissions ? :o Link to comment Share on other sites More sharing options...
Guest Scanno Posted August 5, 2012 Report Share Posted August 5, 2012 (edited) Just for reference, i did some small tests... /system compressed with squashfs [gzip] : 147MB /system compressed with squashfs [lzma2] : 134MB /system compressed with cromfs [lzma2,block=4k] : 129MB Gains are not so huge in compression ratio, but if needed, we could use it... Regarding link2sd, maybe we could patch it to fix it, or create a little script that runs at startup and fixes those permissions ? :o Was thinking about that... but it has to be done before android checks for dalvik-cache. I have reported the issue to the author of link2sd and got a reply that he is looking into it.. Regarding 3g... it seems that people with the build in modem get a signal in the signal bar... let's see if they also get internet... bit strange though.. EDIT: Got a radio logcat showing that 3g seems to work on the internal modem, so why is it not working on my USB dongle. Edited August 5, 2012 by Scanno Link to comment Share on other sites More sharing options...
Guest ejtagle Posted August 6, 2012 Report Share Posted August 6, 2012 Scanno, post the exact dongle model you are using... So we are able to check supported commands... I see D/AT ( 101): AT(16)> AT+CRC=1;+CR=1 I/AT ( 101): AT(16)< +CME ERROR: 14 I/AT ( 101): --- CME_SIM_BUSY E/RIL ( 101): Failed sending command 'AT+CRC=1;+CR=1' Seems some internal operation in the GPRS modem is taking too long ... Maybe just adding an small delay could solve this problem ;) -- Sometimes, it gets hard to write a generic huawei 3G implementation ... :S - Link to comment Share on other sites More sharing options...
Guest Scanno Posted August 6, 2012 Report Share Posted August 6, 2012 Scanno, post the exact dongle model you are using... So we are able to check supported commands... I see D/AT ( 101): AT(16)> AT+CRC=1;+CR=1 I/AT ( 101): AT(16)< +CME ERROR: 14 I/AT ( 101): --- CME_SIM_BUSY E/RIL ( 101): Failed sending command 'AT+CRC=1;+CR=1' Seems some internal operation in the GPRS modem is taking too long ... Maybe just adding an small delay could solve this problem ;) -- Sometimes, it gets hard to write a generic huawei 3G implementation ... :S - I have e153. I seem to remember Cass had a similar problem. He had a e220 i think. If you need more info, or you need me to send an AT string to the modem, let me know. Link to comment Share on other sites More sharing options...
Guest HypoTurtle Posted August 6, 2012 Report Share Posted August 6, 2012 Just for reference, i did some small tests... /system compressed with squashfs [gzip] : 147MB /system compressed with squashfs [lzma2] : 134MB /system compressed with cromfs [lzma2,block=4k] : 129MB Gains are not so huge in compression ratio, but if needed, we could use it... Regarding link2sd, maybe we could patch it to fix it, or create a little script that runs at startup and fixes those permissions ? :o Sort of off topic here, but I'm trying to utilise squashfs on another device, but doesn't want to work. Have enabled squash in the kernel, squashed the relevent folders and edited the init file in initrd. Is there anything blantantly obvious that I've overlooked, or is there a different squashfs script to be used for android?. In terms of the link2sd topic have you considered using a script that mounts the ext partition as /data. and wouldn't think it too difficult to mount an additional ext as /system/app. Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now