2850 replies to this topic

[Daedric1383]

ejtagle, a quick question if i may, do you happen to know the configure clock speed of the sdhci controller ?

[ejtagle]

Daedric1383, on 14 December 2012 - 02:57 AM, said:

ejtagle, a quick question if i may, do you happen to know the configure clock speed of the sdhci controller ?

48Mhz... is the base clock used to derive all internal clockings...

[Daedric1383]

ejtagle, on 15 December 2012 - 10:02 PM, said:

48Mhz... is the base clock used to derive all internal clockings...

Thanks. I just have a feeling there's something wrong with our micro sd card readers...

Edited by Daedric1383, 17 December 2012 - 12:01 AM.

[Scanno]

I am having some strange sound problems with 4.2.1. When using the volume buttons, I can see the volume indicator moving, but the sound level stays the same. When I restart an app, the app uses the new volume level, but changing the level while the app is active does not change the actual volume until I restart the app again.... Anyone else seeing the same problem?

It seems like when an audio stream is opened, volume changes are not applied to the current open audio stream... Cold that be possible?

Edited by Scanno, 19 December 2012 - 04:19 PM.

[ejtagle]

Scanno, on 19 December 2012 - 02:19 PM, said:

I am having some strange sound problems with 4.2.1. When using the volume buttons, I can see the volume indicator moving, but the sound level stays the same. When I restart an app, the app uses the new volume level, but changing the level while the app is active does not change the actual volume until I restart the app again.... Anyone else seeing the same problem?

It seems like when an audio stream is opened, volume changes are not applied to the current open audio stream... Cold that be possible?

Strange... unless audio volume is setting the volume of something different, such as voice volume...

[ejtagle]

Finally, i got some time to fix the mic issues on the JB4.2 on the shuttle. Attached the patch to the audio_hw.c (part of the lunch target for shuttle) that fixes audio input fhrough mic

Attached Files

•  audio.rar   10.01K   5 downloads

[Scanno]

ejtagle, on 20 December 2012 - 02:36 AM, said:

Strange... unless audio volume is setting the volume of something different, such as voice volume...

It seems it is setting a different volume.

[Scanno]

ejtagle, on 23 December 2012 - 04:12 AM, said:

Finally, i got some time to fix the mic issues on the JB4.2 on the shuttle. Attached the patch to the audio_hw.c (part of the lunch target for shuttle) that fixes audio input fhrough mic

Tanks. Will have a look at this soon.

[ejtagle]

Also, I have fixed some bugs in the USB camera library.. Now, the camera always initializes (previously, sometimes it failed to properly init) and also, now the camera is turned ON only when under use. This will save battery!

Attached Files

•  libcamera.rar   78.7K   5 downloads

[ejtagle]

Also , an small fix on the kernel side. Sometimes uarts were trying to use an incorrect clock when trying to set a high speed connection, such as the bluetooth connection. Also fixed it.

Attached Files

•  board-shuttle-uart.rar   1.62K   7 downloads

[Scanno]

ejtagle, on 23 December 2012 - 04:12 AM, said:

Finally, i got some time to fix the mic issues on the JB4.2 on the shuttle. Attached the patch to the audio_hw.c (part of the lunch target for shuttle) that fixes audio input fhrough mic

Eduardo,
With this new audio_hw.c, i am not getting any sound out of my tablet. Putting back the original audo_hw.c and i got sound back. Doing a diff between the files, shows that there are many many differences.

This is the audio_hw,c that i am using and is working fine (except for the big crackle when th card gets initialized the first time):
 audio_hw.c.zip   9.78K   4 downloads

But offcourse the microphone is not working.

Edited by Scanno, 28 December 2012 - 09:09 PM.

[fosser2]

ejtagle, on 24 December 2012 - 06:52 AM, said:

Also , an small fix on the kernel side. Sometimes uarts were trying to use an incorrect clock when trying to set a high speed connection, such as the bluetooth connection. Also fixed it.

Thanks, this fixed some clock errors we were having!

[ejtagle]

Scanno, on 28 December 2012 - 09:08 PM, said:

Eduardo,
With this new audio_hw.c, i am not getting any sound out of my tablet. Putting back the original audo_hw.c and i got sound back. Doing a diff between the files, shows that there are many many differences.

This is the audio_hw,c that i am using and is working fine (except for the big crackle when th card gets initialized the first time):
audio_hw.c.zip

But offcourse the microphone is not working.

The changes you see were required to make the mic work again in jb4.2. The problem was that Google redefined the constants used to select the audio source. Before the redefinition, each audio source had an associated bit in the audio source bitfield, and that bit was unique. But, after the redefinition, each audio source has a unique bit, but also a shared bit that tells that is is an input source. So, expressions such as
(source & MIC_SOURCE), that previously were true only when dealing with the mic, now are always true for all input sources. The result was that Bt audiop was selected as audio input source, instead of mic. What i did was to mask out the offending bit (that tells we are dealing with an input source). That way, the audio driver is able to again properly select the audio source as requested by the framework.

I redid the porting on thedriver you posted. Hope this time it works!

Attached Files

•  audio.rar   9.92K   3 downloads

[Scanno]

ejtagle, on 30 December 2012 - 02:02 AM, said:

The changes you see were required to make the mic work again in jb4.2. The problem was that Google redefined the constants used to select the audio source. Before the redefinition, each audio source had an associated bit in the audio source bitfield, and that bit was unique. But, after the redefinition, each audio source has a unique bit, but also a shared bit that tells that is is an input source. So, exp<b></b>ressions such as
(source & MIC_SOURCE), that previously were true only when dealing with the mic, now are always true for all input sources. The result was that Bt audiop was selected as audio input source, instead of mic. What i did was to mask out the offending bit (that tells we are dealing with an input source). That way, the audio driver is able to again properly select the audio source as requested by the framework.

I redid the porting on thedriver you posted. Hope this time it works!

Thanks i will give it a try

Edit: it seems to be working

Edited by Scanno, 31 December 2012 - 06:54 PM.

[DerArtem]

Hello,

I have also started porting 4.2 to the Folio 100. You did an amazing job! Thanks

For the audio driver I have switched to use the audio lib of the Asus Grouper / Nexus 7:

https://android.goog...4.2.1_r1/audio/

It looks very nice and the configuration is done in mixer_paths.xml instead of the source.
It only lacks HDMI output but this should not be a problem to add. Maybe you should use this too?

[ejtagle]

DerArtem, on 02 January 2013 - 11:41 PM, said:

Hello,

I have also started porting 4.2 to the Folio 100. You did an amazing job! Thanks

For the audio driver I have switched to use the audio lib of the Asus Grouper / Nexus 7:

https://android.goog...4.2.1_r1/audio/

It looks very nice and the configuration is done in mixer_paths.xml instead of the source.
It only lacks HDMI output but this should not be a problem to add. Maybe you should use this too?

The problem ,unfortunately, will be the hdmi audio.. ... Tegra2 has different ports for codec and HDMI, and hte routing can't be expressed in the .xml file. It would require modifications, Eventually, those modifications would give you the auido_hw.cwe are using, but, instead of having hardcoded routing tables, you would read the audio routing tables from the xml file. It is nearly the same thing.. Modifications are required in all cases :S

[Borkata]

DerArtem, on 02 January 2013 - 11:41 PM, said:

Hello,

I have also started porting 4.2 to the Folio 100. You did an amazing job! Thanks

For the audio driver I have switched to use the audio lib of the Asus Grouper / Nexus 7:

https://android.goog...4.2.1_r1/audio/

It looks very nice and the configuration is done in mixer_paths.xml instead of the source.
It only lacks HDMI output but this should not be a problem to add. Maybe you should use this too?

I have already done the implementation for us here https://github.com/n...7007a05248c858c

Actually currently I am using modified version of latest ejtangle, since I like some of the improvements he has

[docck]

Don't know maybe it'd be helpful. One fellow from 4pda.ru forum (Ganster41) made working bluetooth for 4.2.1 rom on ARM6 ZTE Blade phone. Sources are on his github https://github.com/a...072bfac5f59cc86

[ejtagle]

docck, on 12 January 2013 - 03:26 PM, said:

Don't know maybe it'd be helpful. One fellow from 4pda.ru forum (Ganster41) made working bluetooth for 4.2.1 rom on ARM6 ZTE Blade phone. Sources are on his github https://github.com/a...072bfac5f59cc86

The problem we have is that the Atheros bluetooth chip uses the BCSP protocol instead of the H4 protocol to communicate the bt stack thru the Tegra UART to the bluetooth chipset. This protocol is a bluecore proprietary protocol that encapsulates the H4 protocol into packets with header and checksum, and implements a retry if failed mechanism that the H4 protocol does not implement.
Most bluetooth chipsets use the H4 protocol, so they will work with the broadcom stack. But our bluecore based bluetooth chipset only accepts BCSP,that the broadcom stack does not implement. I havent finished the implementation yet, but it should not be an impossible task.... I am still working on it...

[Scanno]

ejtagle, on 13 January 2013 - 04:32 AM, said:

The problem we have is that the Atheros bluetooth chip uses the BCSP protocol instead of the H4 protocol to communicate the bt stack thru the Tegra UART to the bluetooth chipset. This protocol is a bluecore proprietary protocol that encapsulates the H4 protocol into packets with header and checksum, and implements a retry if failed mechanism that the H4 protocol does not implement.
Most bluetooth chipsets use the H4 protocol, so they will work with the broadcom stack. But our bluecore based bluetooth chipset only accepts BCSP,that the broadcom stack does not implement. I havent finished the implementation yet, but it should not be an impossible task.... I am still working on it...

Thanks that you are still working on BT