Guest ejtagle Posted August 16, 2011 Report Share Posted August 16, 2011 I have seen that in the latest image builds they have changed, not only the maximum volume, but also the bias voltage. That is an error that actually CAUSES clipping .. The vdd settings i have used for the kernel must be kept the way they are! --- The ONLY setting that can be adjusted is the maximum volume... vdd is FIXED by the hardware design , and platform data MUST match the hardwre design - That is why vdd settings of the ALC should not be modified. Regards, Eduardo! Well, i did the measurements... Headphone level should be perfect as it is. Speaker volume in the .32 kernel is half the volume of the .36 kernel. I found a bug in the ALC codec driver volume scaling. So i fixed it. And also i have filled in the values in the ALC platform data to match the volume levels of the .32 kernel. Please, test it. It should be as loud as the .32 kernel, but NOT louder. Regards. Eduardo audio.rar Link to comment Share on other sites More sharing options...
Guest stiggy2011 Posted August 16, 2011 Report Share Posted August 16, 2011 Well, i did the measurements... Headphone level should be perfect as it is. Speaker volume in the .32 kernel is half the volume of the .36 kernel. I found a bug in the ALC codec driver volume scaling. So i fixed it. And also i have filled in the values in the ALC platform data to match the volume levels of the .32 kernel. Please, test it. It should be as loud as the .32 kernel, but NOT louder. Regards. Eduardo HI again, Don't mean to pester you but even with this patch, I'm still getting issues with the headphone output. Above 50% and you can hear distortion, below 50% and it's almost too quiet to be usable. I know you've measured the output/checked the code, but if you listen to a mp3 it's obvious that it's still not right currently! :) Speaker output seems almost perfect however. Certainly very very usable. The only thing I find weird, is that whilst the output is considerably quieter now it still distorts when turned up above about 80%, as it did previously. The speakers seem to be getting less power now at 100% than they were before at 65%, so the distortion is not from them being overpowered. It seems to my feeble mind that the signal still clips pre-amplification when turned above 80%, or 50% when using headphones? Thanks again, Steve Link to comment Share on other sites More sharing options...
Guest ejtagle Posted August 17, 2011 Report Share Posted August 17, 2011 (edited) HI again, Don't mean to pester you but even with this patch, I'm still getting issues with the headphone output. Above 50% and you can hear distortion, below 50% and it's almost too quiet to be usable. I know you've measured the output/checked the code, but if you listen to a mp3 it's obvious that it's still not right currently! :) Speaker output seems almost perfect however. Certainly very very usable. The only thing I find weird, is that whilst the output is considerably quieter now it still distorts when turned up above about 80%, as it did previously. The speakers seem to be getting less power now at 100% than they were before at 65%, so the distortion is not from them being overpowered. It seems to my feeble mind that the signal still clips pre-amplification when turned above 80%, or 50% when using headphones? Thanks again, Steve Yes, you were right. I did several measurements looking at the headphone output with a digital scope, and i found that there is assimetrical clipping of the audio signal, and it starts to happen when the volume setting is above 50% ... A much less severe case of assimetrical clipping is also seen on the speaker amplifier terrninals when going above 80% of the maximum volume. But, before anyone starts to panic... No, the clipping WONT kill your speakers. It is just a soft clipping. But, nevertheless, it causes an very unpleasant audio distorsion ... I have tracked this issue to a very bad explanation on the setting of the bias supply registers in the ALC codec datasheet. After several experiments, and their associated measures, the bias setting register seems to be expressed as a percent of the analog supply voltage, and not as an absolute voltage, as the datasheet says. I modified the ALC codec and some associated data structures to reflect the new collected data. With those modifications, the ALC does NOT distort or clip the audio in any measurable way, even if setting the audio volume to maximum -- And trust me, it sounds much better than before. Attached the modified files ;) -- Please, tell me if any new problems are found with those, but, according to measurements, and to just listening to the audio, seems the distorsion is gone Eduardo PS> I am wondering if there is something more to look for in this kernel... Bluetooth maybe ? - Otherwise, i'll continue investigations on LP0 power saving mode PS2: When i did the previous set of measurements (in the previous post) i was just looking to adjust audio levels. I never tried it at high volumes (i did not want to blow my speakers while testing!) ... that is why i didn't notice the assymetrical clipping. But now, the new measures were done at maximum volume, so i am positively sure there is NO clipping with the new modifications!audio-reffix.rar Edited August 17, 2011 by ejtagle Link to comment Share on other sites More sharing options...
Guest stiggy2011 Posted August 17, 2011 Report Share Posted August 17, 2011 Yes, you were right. I did several measurements looking at the headphone output with a digital scope, and i found that there is assimetrical clipping of the audio signal, and it starts to happen when the volume setting is above 50% ... A much less severe case of assimetrical clipping is also seen on the speaker amplifier terrninals when going above 80% of the maximum volume. But, before anyone starts to panic... No, the clipping WONT kill your speakers. It is just a soft clipping. But, nevertheless, it causes an very unpleasant audio distorsion ... I have tracked this issue to a very bad explanation on the setting of the bias supply registers in the ALC codec datasheet. After several experiments, and their associated measures, the bias setting register seems to be expressed as a percent of the analog supply voltage, and not as an absolute voltage, as the datasheet says. I modified the ALC codec and some associated data structures to reflect the new collected data. With those modifications, the ALC does NOT distort or clip the audio in any measurable way, even if setting the audio volume to maximum -- And trust me, it sounds much better than before. Attached the modified files ;) -- Please, tell me if any new problems are found with those, but, according to measurements, and to just listening to the audio, seems the distorsion is gone Eduardo PS> I am wondering if there is something more to look for in this kernel... Bluetooth maybe ? - Otherwise, i'll continue investigations on LP0 power saving mode PS2: When i did the previous set of measurements (in the previous post) i was just looking to adjust audio levels. I never tried it at high volumes (i did not want to blow my speakers while testing!) ... that is why i didn't notice the assymetrical clipping. But now, the new measures were done at maximum volume, so i am positively sure there is NO clipping with the new modifications! Thanks very much! I'll try this out ASAP and let you know - though I'm sure the problem is resolved. :) Haha, you've done such an amazing job you're running out of work! I know Rene (rebel1) is looking into the bluetooth but I'm not sure how far he's gotten with it. Certainly, it needs further work. Also, there appear to be some issues currently with automatic switching from USB slave to host mode I'm told though rebel1 may be able to provide more info there. Steve Link to comment Share on other sites More sharing options...
Guest rebel1 Posted August 17, 2011 Report Share Posted August 17, 2011 Yes, you were right. I did several measurements looking at the headphone output with a digital scope, and i found that there is assimetrical clipping of the audio signal, and it starts to happen when the volume setting is above 50% ... A much less severe case of assimetrical clipping is also seen on the speaker amplifier terrninals when going above 80% of the maximum volume. But, before anyone starts to panic... No, the clipping WONT kill your speakers. It is just a soft clipping. But, nevertheless, it causes an very unpleasant audio distorsion ... I have tracked this issue to a very bad explanation on the setting of the bias supply registers in the ALC codec datasheet. After several experiments, and their associated measures, the bias setting register seems to be expressed as a percent of the analog supply voltage, and not as an absolute voltage, as the datasheet says. I modified the ALC codec and some associated data structures to reflect the new collected data. With those modifications, the ALC does NOT distort or clip the audio in any measurable way, even if setting the audio volume to maximum -- And trust me, it sounds much better than before. Attached the modified files ;) -- Please, tell me if any new problems are found with those, but, according to measurements, and to just listening to the audio, seems the distorsion is gone Eduardo PS> I am wondering if there is something more to look for in this kernel... Bluetooth maybe ? - Otherwise, i'll continue investigations on LP0 power saving mode PS2: When i did the previous set of measurements (in the previous post) i was just looking to adjust audio levels. I never tried it at high volumes (i did not want to blow my speakers while testing!) ... that is why i didn't notice the assymetrical clipping. But now, the new measures were done at maximum volume, so i am positively sure there is NO clipping with the new modifications! Hi, you made it again, after this last patch, audio works perfect. About usb and bluetooth i need to recheck and report it later. About usb , when i remember right, it breaks usb after suspend. Rebel1 Link to comment Share on other sites More sharing options...
Guest ejtagle Posted August 17, 2011 Report Share Posted August 17, 2011 Hi, you made it again, after this last patch, audio works perfect. About usb and bluetooth i need to recheck and report it later. About usb , when i remember right, it breaks usb after suspend. Rebel1 Well... seems there are still things to do: -Microphone... Should be working, but,... -USB host mode... I am using the OTG interface of Tegra2 to switch between modes.... Will have to check if something is missing on resume -Bluetooth/WLAn. I do suspect there is something missing to be enabled. The culprit could be the power management driver i wrote for it. As a workaround, we could disable powering the bluetooth module on suspend .. Until we are sure Regards, Eduardo Link to comment Share on other sites More sharing options...
Guest BillyBobJoe Posted August 17, 2011 Report Share Posted August 17, 2011 Yes, you were right. I did several measurements looking at the headphone output with a digital scope, and i found that there is assimetrical clipping of the audio signal, and it starts to happen when the volume setting is above 50% ... A much less severe case of assimetrical clipping is also seen on the speaker amplifier terrninals when going above 80% of the maximum volume. But, before anyone starts to panic... No, the clipping WONT kill your speakers. It is just a soft clipping. But, nevertheless, it causes an very unpleasant audio distorsion ... I have tracked this issue to a very bad explanation on the setting of the bias supply registers in the ALC codec datasheet. After several experiments, and their associated measures, the bias setting register seems to be expressed as a percent of the analog supply voltage, and not as an absolute voltage, as the datasheet says. I modified the ALC codec and some associated data structures to reflect the new collected data. With those modifications, the ALC does NOT distort or clip the audio in any measurable way, even if setting the audio volume to maximum -- And trust me, it sounds much better than before. Attached the modified files ;) -- Please, tell me if any new problems are found with those, but, according to measurements, and to just listening to the audio, seems the distorsion is gone Eduardo PS> I am wondering if there is something more to look for in this kernel... Bluetooth maybe ? - Otherwise, i'll continue investigations on LP0 power saving mode PS2: When i did the previous set of measurements (in the previous post) i was just looking to adjust audio levels. I never tried it at high volumes (i did not want to blow my speakers while testing!) ... that is why i didn't notice the assymetrical clipping. But now, the new measures were done at maximum volume, so i am positively sure there is NO clipping with the new modifications! Ed I am glad to see that some poeple still have ocilloscope and aren't afraid to use them. Things to look at, the big thing that has alluded many is the camera. In fact you could potentially get a bonus from the nice guys at TabletRoms.com..... Billy.. Link to comment Share on other sites More sharing options...
Guest ejtagle Posted August 17, 2011 Report Share Posted August 17, 2011 Ed I am glad to see that some poeple still have ocilloscope and aren't afraid to use them. Things to look at, the big thing that has alluded many is the camera. In fact you could potentially get a bonus from the nice guys at TabletRoms.com..... Billy.. And the camera, at least at the kernel level, is working ... The problem here seems to be that HC tries to use the tegra camera, but on Vega, there is no camera interfaced to the tegra SoC. Instead, the use a very standard USB camera, that is recognized by the kernel. We just need an android camera support library that take standard cameras, instead of trying to use the tegra camera ;) Link to comment Share on other sites More sharing options...
Guest Cass67 Posted August 17, 2011 Report Share Posted August 17, 2011 And the camera, at least at the kernel level, is working ... The problem here seems to be that HC tries to use the tegra camera, but on Vega, there is no camera interfaced to the tegra SoC. Instead, the use a very standard USB camera, that is recognized by the kernel. We just need an android camera support library that take standard cameras, instead of trying to use the tegra camera ;) I looked at this today, tried a quick addition of the stock nv lib that's called on the stock ROM when launching camera app, added that app too. It required another nv lib, it was added and it failed looking for /dev/nvrm or something like that.. not sure if init should be creating that on stock ROM at boot time but I need to look farther at this and compare stock /dev tree for a clue... something tells me though we may replace all nv libs and still hit an issue.. needs more time to look at though to be sure. Link to comment Share on other sites More sharing options...
Guest ejtagle Posted August 17, 2011 Report Share Posted August 17, 2011 I looked at this today, tried a quick addition of the stock nv lib that's called on the stock ROM when launching camera app, added that app too. It required another nv lib, it was added and it failed looking for /dev/nvrm or something like that.. not sure if init should be creating that on stock ROM at boot time but I need to look farther at this and compare stock /dev tree for a clue... something tells me though we may replace all nv libs and still hit an issue.. needs more time to look at though to be sure. Probably going the wrong way here... the camera is a USB camera. The libraries should not be referencing nvidia drivers (nvrm = nvidia resource manager driver)... Trust me ... this will be hard to solve ;) Link to comment Share on other sites More sharing options...
Guest stiggy2011 Posted August 17, 2011 Report Share Posted August 17, 2011 How did this work in the old vegacomb 1.7 beta based on 2.6.32? Did the kernel somehow show a tegra2 interfaced webcam or was there a library for a standard USB camera in this release? Link to comment Share on other sites More sharing options...
Guest Cass67 Posted August 17, 2011 Report Share Posted August 17, 2011 It worked on vegacomb? I was under the impression it worked on nothing but stock.. OMX libs may be the problem for us.. nv libs may be transferable but OMX not so much.. Link to comment Share on other sites More sharing options...
Guest stiggy2011 Posted August 17, 2011 Report Share Posted August 17, 2011 It worked on vegacomb? I was under the impression it worked on nothing but stock.. OMX libs may be the problem for us.. nv libs may be transferable but OMX not so much.. Ah. That'll be that then I suspect. With there being so few models of Honeycomb tablet out there, we're going to be lucky to find one using a USB camera instead of the tegra internal method. If we can't use the library from 2.2 is there any chance of writing a wrapper?.. Is it even worth trying? I know personally I've never used the camera really anyway. The quality is pretty shocking! Link to comment Share on other sites More sharing options...
Guest Cass67 Posted August 17, 2011 Report Share Posted August 17, 2011 I suspect wrapper may be difficult without source.. cm7 may help but I dunno to be honest.. Link to comment Share on other sites More sharing options...
Guest ejtagle Posted August 17, 2011 Report Share Posted August 17, 2011 (edited) I suspect wrapper may be difficult without source.. cm7 may help but I dunno to be honest.. We need a library that uses standard video for linux2 interfases to expose the camera to android... i am sure that that library exists as a reference library.<div><br></div><div>Id guess the library to look for is libcamera.so . That is the only one referencing Nvidia drivers</div> Edited August 17, 2011 by ejtagle Link to comment Share on other sites More sharing options...
Guest Cass67 Posted August 17, 2011 Report Share Posted August 17, 2011 Probably going the wrong way here... the camera is a USB camera. The libraries should not be referencing nvidia drivers (nvrm = nvidia resource manager driver)... Trust me ... this will be hard to solve ;) Just followed the trail on 2.2 advent camera launch and that's what it came up with... Could be advent uses a wrapper themselves.. I'll dig in later and show what I see.. I don't doubt it will be hard ;) Link to comment Share on other sites More sharing options...
Guest BillyBobJoe Posted August 17, 2011 Report Share Posted August 17, 2011 Just followed the trail on 2.2 advent camera launch and that's what it came up with... Could be advent uses a wrapper themselves.. I'll dig in later and show what I see.. I don't doubt it will be hard ;) Cass, et al; If its any help just flashed latest nightly of Cyanogen Gingerbread and they have the camera working. Android version 2.3.5 Kernel 2.6.32.39 Billy.. PS Get FC as soon as I booted so they may be more than a little upset by the new VegaComb Link to comment Share on other sites More sharing options...
Guest Cass67 Posted August 17, 2011 Report Share Posted August 17, 2011 Cass, et al; If its any help just flashed latest nightly of Cyanogen Gingerbread and they have the camera working. Android version 2.3.5 Kernel 2.6.32.39 Billy.. PS Get FC as soon as I booted so they may be more than a little upset by the new VegaComb Thanks man ill take a look ... may be no help as i suspect OMX will be in play and im not sure that will be transferrable but its worth a look.. FC on build 6 ?? i get none its almost perfect :) Link to comment Share on other sites More sharing options...
Guest brucelee666 Posted August 18, 2011 Report Share Posted August 18, 2011 (edited) re. camera - If my memory serves me correctly BumbleBee(guy who did vega kernel for cm) made a few changes to something (not sure what probably kernel) to get the camera working in CM, had problems with powering the thing due to how advent had used scripts for power/sleep/wake. CM uses the same libcamera.so as the stock vega libcamera.so but different libcamera_client.so and libcamerservice.so. From what ejtagle has said the new kernel creates the camera as a video4linux device on "dev/video" ?, if thats the case then I would guess a new libcamera.so would have to be written for this, found this which appears to be someones attempt at writing a libcamera video4linux library (have not compiled or tested anything so don't know if it works but would be a start):- video4linux libcamera Also if someone wants to write a new libcamera this info may help (yes its for a TI camera but process would be the same):- Camera porting guide From the looks of the original libcamera.so it may have been created as a uvcvideo driver or even a video4linux as there is mention of converting v4l2-yuv422, its possible the new libjpeg or libmedia are different as these were possibly used for saving pics/movies in the original or the newer libnvrm_graphics/libnvdispmgr_d are different (see original libcamera for libs used to build it, no mention of omx like the newer honeycomb libcamera). Edited August 18, 2011 by brucelee666 Link to comment Share on other sites More sharing options...
Guest Cass67 Posted August 18, 2011 Report Share Posted August 18, 2011 re. camera - If my memory serves me correctly BumbleBee(guy who did vega kernel for cm) made a few changes to something (not sure what probably kernel) to get the camera working in CM, had problems with powering the thing due to how advent had used scripts for power/sleep/wake. CM uses the same libcamera.so as the stock vega libcamera.so but different libcamera_client.so and libcamerservice.so. From what ejtagle has said the new kernel creates the camera as a video4linux device on "dev/video" ?, if thats the case then I would guess a new libcamera.so would have to be written for this, found this which appears to be someones attempt at writing a libcamera video4linux library (have not compiled or tested anything so don't know if it works but would be a start):- video4linux libcamera Also if someone wants to write a new libcamera this info may help (yes its for a TI camera but process would be the same):- Camera porting guide From the looks of the original libcamera.so it may have been created as a uvcvideo driver or even a video4linux as there is mention of converting v4l2-yuv422, its possible the new libjpeg or libmedia are different as these were possibly used for saving pics/movies in the original. Thanks man .. all good info .. problem is CM has source we do not .. gonna be fun times ahead .. thats for sure :) Link to comment Share on other sites More sharing options...
Guest ejtagle Posted August 18, 2011 Report Share Posted August 18, 2011 Well.... What i am about to post has... emmm... i may say no strict analysis, but, believe it or not, i think we could use the libcamera.so from the .32 kernel to enable the camera in the .36 kernel... What??? -- I am sure you are telling, and asking yourself if i am crazy for telling so... But, i have a theory behind this: While HC3.2 is a "new" incarnation of Android, as most of you, specially the ones who have worked in a software company should know, every company tries to reuse as much as possible the already developed software modules.... And Android is no exception to this rule. libcamera.so exists even in android 2.2 (froyo). But it just supported 1 camera at a time. Android 2.3(gingerbread) added support for more than one camera, but, the only changes that were made to the library were renaming the 2 entrypoints that were present in previous versions, adding a 3rd entry point and adding extra parameters to those entrypoints. No other changes!!. On android 2.2, the only required entrypoint was extern "C" sp<CameraHardwareInterface> openCameraHardware(); That returns an instance of CameraHardwareInterface On android 2.3, the 3 required entrypoints are extern "C" int HAL_getNumberOfCameras(); /* Returns the number of cameras */ extern "C" void HAL_getCameraInfo(int cameraId, struct CameraInfo *cameraInfo); /* Returns info about an specific camera */ extern "C" sp<CameraHardwareInterface> HAL_openCameraHardware(int /*cameraId*/); /* That returns an instance of CameraHardwareInterface for an specific camera */ I decompiled the .36 libcamera.so from the xoom dump, and guess what?? - It is exporting the SAME 3 entrypoints of android 2.3! -- So, i think there are good chances that Google didnt change the camera api from 2.3 to 3.2 ;) If that is true, we need to write a wrapper for the original 2.2 libcamera.so, that exports the 3 new entrypoints, telling there is just one camera, giving the information for that camera, and when the HAL_openCameraHardware() is called, call the original openCameraHardware of the .32 library... Seems it is not a complex thing... But, we dont even have to write that wrapper. It was already written and we can take it from Cyanogen Gingerbread Well, i am just guessing.. but... there are chances it could work - and i think its worth a try! :D PS> Just as a curiosity, attached the code of the proposed wrapper, the same Cyanogen should be using...wrapper.rar Link to comment Share on other sites More sharing options...
Guest Cass67 Posted August 18, 2011 Report Share Posted August 18, 2011 Well.... What i am about to post has... emmm... i may say no strict analysis, but, believe it or not, i think we could use the libcamera.so from the .32 kernel to enable the camera in the .36 kernel... What??? -- I am sure you are telling, and asking yourself if i am crazy for telling so... But, i have a theory behind this: While HC3.2 is a "new" incarnation of Android, as most of you, specially the ones who have worked in a software company should know, every company tries to reuse as much as possible the already developed software modules.... And Android is no exception to this rule. libcamera.so exists even in android 2.2 (froyo). But it just supported 1 camera at a time. Android 2.3(gingerbread) added support for more than one camera, but, the only changes that were made to the library were renaming the 2 entrypoints that were present in previous versions, adding a 3rd entry point and adding extra parameters to those entrypoints. No other changes!!. On android 2.2, the only required entrypoint was extern "C" sp<CameraHardwareInterface> openCameraHardware(); That returns an instance of CameraHardwareInterface On android 2.3, the 3 required entrypoints are extern "C" int HAL_getNumberOfCameras(); /* Returns the number of cameras */ extern "C" void HAL_getCameraInfo(int cameraId, struct CameraInfo *cameraInfo); /* Returns info about an specific camera */ extern "C" sp<CameraHardwareInterface> HAL_openCameraHardware(int /*cameraId*/); /* That returns an instance of CameraHardwareInterface for an specific camera */ I decompiled the .36 libcamera.so from the xoom dump, and guess what?? - It is exporting the SAME 3 entrypoints of android 2.3! -- So, i think there are good chances that Google didnt change the camera api from 2.3 to 3.2 ;) If that is true, we need to write a wrapper for the original 2.2 libcamera.so, that exports the 3 new entrypoints, telling there is just one camera, giving the information for that camera, and when the HAL_openCameraHardware() is called, call the original openCameraHardware of the .32 library... Seems it is not a complex thing... But, we dont even have to write that wrapper. It was already written and we can take it from Cyanogen Gingerbread Well, i am just guessing.. but... there are chances it could work - and i think its worth a try! :D PS> Just as a curiosity, attached the code of the proposed wrapper, the same Cyanogen should be using... FARK me .. showing off your legendary status again :) thanks .. ill look into this as soon as i get a chance ;) Cheers Cass Link to comment Share on other sites More sharing options...
Guest the_corvus Posted August 18, 2011 Report Share Posted August 18, 2011 (edited) About BT. With some hacks i get a hci0 device and start it from settings menu, but i get this errors: [ 248.104615] h4_recv: Frame Reassembly Failed [ 248.342860] tegra_uart tegra_uart.2: Got frame errors [ 248.342944] tegra_uart tegra_uart.2: Got frame errors [ 248.344632] h4_recv: Frame Reassembly Failed [ 248.592977] tegra_uart tegra_uart.2: Got frame errors [ 248.593059] tegra_uart tegra_uart.2: Got frame errors [ 248.594264] h4_recv: Frame Reassembly Failed [ 248.843112] tegra_uart tegra_uart.2: Got frame errors [ 248.843196] tegra_uart tegra_uart.2: Got frame errors [ 248.844285] h4_recv: Frame Reassembly Failed [ 249.093242] tegra_uart tegra_uart.2: Got frame errors [ 249.093325] tegra_uart tegra_uart.2: Got frame errors [ 249.094283] h4_recv: Frame Reassembly Failed [ 249.343357] tegra_uart tegra_uart.2: Got frame errors [ 249.343440] tegra_uart tegra_uart.2: Got frame errors [ 249.344417] h4_recv: Frame Reassembly Failed And this: / # stty -F /dev/ttyHS2 -a speed 921600 baud;stty: /dev/ttyHS2 line = 15; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 hupcl -cstopb cread clocal crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke This is the correct bauds that i configured the device, so this is correct and is the same speed that was working in 2.2... Any clues? UPDATE: More info... Before exec commands to bring BT up in: /sys/devices/virtual/bluetooth/ There is nothing, once exec there is an hci0 with a bunch of files, so seems that the commands runs ok. But when i exec: #:/ bccmd psget Can't read version info for hci0: Network is down (100) I try to rfkill down and up again, but no luck Corvus. Edited August 18, 2011 by the_corvus Link to comment Share on other sites More sharing options...
Guest BillyBobJoe Posted August 18, 2011 Report Share Posted August 18, 2011 Thanks man ill take a look ... may be no help as i suspect OMX will be in play and im not sure that will be transferrable but its worth a look.. FC on build 6 ?? i get none its almost perfect :) No got several FC's with the Cyanogen ROM on boot from a clean install. Billy.. Link to comment Share on other sites More sharing options...
Guest ejtagle Posted August 18, 2011 Report Share Posted August 18, 2011 About BT. With some hacks i get a hci0 device and start it from settings menu, but i get this errors: [ 248.104615] h4_recv: Frame Reassembly Failed [ 248.342860] tegra_uart tegra_uart.2: Got frame errors [ 248.342944] tegra_uart tegra_uart.2: Got frame errors [ 248.344632] h4_recv: Frame Reassembly Failed [ 248.592977] tegra_uart tegra_uart.2: Got frame errors [ 248.593059] tegra_uart tegra_uart.2: Got frame errors [ 248.594264] h4_recv: Frame Reassembly Failed [ 248.843112] tegra_uart tegra_uart.2: Got frame errors [ 248.843196] tegra_uart tegra_uart.2: Got frame errors [ 248.844285] h4_recv: Frame Reassembly Failed [ 249.093242] tegra_uart tegra_uart.2: Got frame errors [ 249.093325] tegra_uart tegra_uart.2: Got frame errors [ 249.094283] h4_recv: Frame Reassembly Failed [ 249.343357] tegra_uart tegra_uart.2: Got frame errors [ 249.343440] tegra_uart tegra_uart.2: Got frame errors [ 249.344417] h4_recv: Frame Reassembly Failed And this: / # stty -F /dev/ttyHS2 -a speed 921600 baud;stty: /dev/ttyHS2 line = 15; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 hupcl -cstopb cread clocal crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke This is the correct bauds that i configured the device, so this is correct and is the same speed that was working in 2.2... Any clues? UPDATE: More info... Before exec commands to bring BT up in: /sys/devices/virtual/bluetooth/ There is nothing, once exec there is an hci0 with a bunch of files, so seems that the commands runs ok. But when i exec: #:/ bccmd psget Can't read version info for hci0: Network is down (100) I try to rfkill down and up again, but no luck Corvus. There is something here tht makes me think there is a problem with the bitrate the port was set at. The message: [ 249.343357] tegra_uart tegra_uart.2: Got frame errors Is coming from the tegra USART kernel driver. I will check the exact meaning, but, it could be a mismatch between the speed set and the actual speed the port is running at. When running at high speeds, it becomes harder and harder to match the exact requested speed, as the bitrate of the port is created by dividing the source clock of the UART (specified in board-shuttle-clocks.c) by some calculated factor that must be an integer. An error in the real bitrate compared to the desired bitrate higher than 10% will cause framing errors. And that could explain the messages. Even though i haven't investigated this fully, perhaps what it happens is that the initialization of the bluetooth device is done at a lower speed, perhaps much lower, so it succeeds, as getting an exact bitrate is much easier when using low bitrates, than higher ones. But, once initialized, the speed is reprogrammed to a much higher speed, and then communications start to fail. I will try to figure out if this is the cause or not Eduardo PS: I am working on fixing the microphone.... It is nearly done. :) 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