Jump to content

Advent Vega kernel source code now available!


Guest PaulOBrien

Recommended Posts

Guest ejtagle

Sadly still the same problem

This starts to smell like a framework bug,,, I will investigate further... Just for anyone reading, the exact culprit can be found at:

AudioPolicyManagerBase.cpp, function AudioPolicyManagerBase::checkOutputForStrategy(routing_strategy strategy), The exact line causing the Null pointer exception is the next one to the FIXME comment that there is. And the problem is that they are accessing the dstOutputs[0] element, but i do suspect this array has no elements.

The AudioPolicyManagerBase::checkOutputForStrategy(routing_strategy strategy) is called with strategy = STRATEGY_SONIFICATION, from AudioPolicyManagerBase::checkOutputForAllStrategies().

It is either a framework bug, or still something missing either in audio_hw.c or audio_policy.conf... Will investigate further..

Link to comment
Share on other sites

Guest univall

Eduardo/Ejtagle:

I have built a ROM from Scanno's Vegabean repository with the phone functions enabled and report that I am able to make and receive calls on my Viewsonic 10s 3g without any issues or force closes.

The issue I am facing is that sound is not flowing through on the phone call either via speakers or via wired headset. I am trying to figure out what I need to activate in the framework or device source / build files to get this working.

Am willing to build and test out any inputs provided here. Please note I am a newbie to repo, git and patches so helpful hints along with your inputs will make it easier for me to handle. I am quite keen to do this and have sometime on my hands for the next few weeks.

Link to comment
Share on other sites

Guest ejtagle

Eduardo/Ejtagle:

I have built a ROM from Scanno's Vegabean repository with the phone functions enabled and report that I am able to make and receive calls on my Viewsonic 10s 3g without any issues or force closes.

The issue I am facing is that sound is not flowing through on the phone call either via speakers or via wired headset. I am trying to figure out what I need to activate in the framework or device source / build files to get this working.

Am willing to build and test out any inputs provided here. Please note I am a newbie to repo, git and patches so helpful hints along with your inputs will make it easier for me to handle. I am quite keen to do this and have sometime on my hands for the next few weeks.

The audio loopback is fully implemented in the RIL (huawei_generic) ... a part of the shuttle lunch target. We must debug the startup of that audio loopback as soon as a communication is estabhlished...

Link to comment
Share on other sites

Guest univall

The audio loopback is fully implemented in the RIL (huawei_generic) ... a part of the shuttle lunch target. We must debug the startup of that audio loopback as soon as a communication is estabhlished...

Please see attached log captured while I try to make a call to the tablet twice. Is there some other command that can give more relevant data. Hope this can indicate something.

adb-logcat.txt

Link to comment
Share on other sites

Guest ejtagle

Please see attached log captured while I try to make a call to the tablet twice. Is there some other command that can give more relevant data. Hope this can indicate something.

adb logcat *:v -b radio

That will dump the radioo log, that is the place where RIL logs what it is happening... ;)

Link to comment
Share on other sites

Guest univall

adb logcat *:v -b radio

That will dump the radioo log, that is the place where RIL logs what it is happening... ;)

Thank you for the tip. Attached logs - (1) radio-1st.txt call from another phone to the tablet (2) radio-2nd.txt Call made from the tablet to another phone.

Notifications on my tablet (after I end my call) are in strange characters - it seems we are missing a font.

radio-1st.txt

radio-2nd.txt

Link to comment
Share on other sites

Guest ejtagle

This starts to smell like a framework bug,,, I will investigate further... Just for anyone reading, the exact culprit can be found at:

AudioPolicyManagerBase.cpp, function AudioPolicyManagerBase::checkOutputForStrategy(routing_strategy strategy), The exact line causing the Null pointer exception is the next one to the FIXME comment that there is. And the problem is that they are accessing the dstOutputs[0] element, but i do suspect this array has no elements.

The AudioPolicyManagerBase::checkOutputForStrategy(routing_strategy strategy) is called with strategy = STRATEGY_SONIFICATION, from AudioPolicyManagerBase::checkOutputForAllStrategies().

It is either a framework bug, or still something missing either in audio_hw.c or audio_policy.conf... Will investigate further..

I unfortunately have to confirm the problem IS a framework bug Seems the framework has several strategies for audio output. Some of those strategies return more than a device (we will say multiple outputs) in getDeviceForStrategy(). The problem is that the framework then fails to handle that situation and crashes!! .. I assume Nexus7 does not have an HDMI video port, that is why this problem does not show ... But, we do have it, and we are triggering the framework bug while tring to switch to hdmi audio...

Link to comment
Share on other sites

Guest ejtagle

I unfortunately have to confirm the problem IS a framework bug Seems the framework has several strategies for audio output. Some of those strategies return more than a device (we will say multiple outputs) in getDeviceForStrategy(). The problem is that the framework then fails to handle that situation and crashes!! .. I assume Nexus7 does not have an HDMI video port, that is why this problem does not show ... But, we do have it, and we are triggering the framework bug while tring to switch to hdmi audio...

Well, even if there seems to be a bug in the framework, i was able to crafy an audio_policy.conf file that is able to solve the HDMI audio. Tested, and seems to work for me :)

Attached the file. I simply declared hdmi as a mode ot the primary device... :P

audio_policy.rar

Link to comment
Share on other sites

Guest ejtagle

I've been working on the huawei generic ril to make work better and with other huawei dongles.... It should support voice, but not all huawei modules support it ... For example, my e168 does not (at least, with the bundled firmware) ... Nevertheless, USSD calls, and normal call (no audio if no voice support in fw) work... Unfortunately, maybe i have broken data access .. As i have tried to copy what the original huawei supplied RIL did (it uses RNDIS instead of PPP...)... Well, i think it will require a little bit more of debugging, but i post it here for those of you who would like to try it... ;) -- Try voice call, try USSD, try sms, try Data connection ...

huawei-generic-19aug.rar

Link to comment
Share on other sites

Guest fosser2

Hey ejtagle,

I'm looking through how you guys implamented audio in 3.1. I'm intrested in how you enabled the CDEV clocks for audio. Since the CDEV clocks are not being called in the board-shuttle-clocks.c where exactly is CDEV being enabled? I ask this because we're trying to get the G-Tablet to register audio devices but it will only enable w/ the proper CDEV added to the clocks. Any idea what I'm missing? Thanks :)

-fosser2

Link to comment
Share on other sites

Guest ejtagle

Hey ejtagle,

I'm looking through how you guys implamented audio in 3.1. I'm intrested in how you enabled the CDEV clocks for audio. Since the CDEV clocks are not being called in the board-shuttle-clocks.c where exactly is CDEV being enabled? I ask this because we're trying to get the G-Tablet to register audio devices but it will only enable w/ the proper CDEV added to the clocks. Any idea what I'm missing? Thanks :)

-fosser2

You are trying to address one of the most changing aspects of the tegra kernel... I lost a lot of time following that one... Finally, it was relatively easy... Yoy dont have to declare and/or enable cdev (=pll_a_out0) in tegra_clk_init_table. All you need to make it work is to make sure it is properly configured in tegra_pingroup_config

I mean,

{TEGRA_PINGROUP_CDEV1, TEGRA_MUX_PLLA_OUT, TEGRA_PUPD_PULL_DOWN, TEGRA_TRI_NORMAL},

Then ,all configuration of plls as required to get an specific audio sampling rate will be taken care of by tegra_das_device

The initialization order is extremely importan here, as you need the clocks to be enabled before the audio codec i2c registers can be accessed. Use exactly the same order as i did in board-shuttle-audio.c, i mean the shuttle_i2s_devices

Also, look at the shuttle_audio_register_devices function. It is important to register first the platform devices, and then the i2c devices. We NEED DAS to be registered before any codec access is done!

Also, in tegra_alc5624.c, look into the function tegra_snd_shuttle_probe. The call to tegra_asoc_utils_init is the one that enables the cdev clock. It is pretty important for this call to be done as soon as possible. Use the tegra_alc5624.c as a template on how and when to enable / disable and when to call asoc utils. Otherwise, cdev clocks won-t be enabled when you need them...

And , there is very important point in the codec source itself. Look into alc5624.c, specifically the functions alc5624_i2c_probe and alc5624_probe

The Alsa SOC calls alc5624_i2c_probe before calling the tegra_snd_shuttle_probe (tegra_alc5624.c). So, at this point, the cdev clock is not running, and codec registers can't be accessed or probed. You need to defer codec register access to alc5624_probe. Plese, use alc5624.c as a template on when to access registers.

The reason behind all those dependencies is that the subsystem caling the *_i2c_probe is the i2c subsystem, And this subsystem initializes before Alsa. Alsa just tries to assemble a working sound subsystem, by calling first the sound_card driver (in tegra_slc5624.c) that gives the information on the relationships between the codec and i2s and das. Then, it will just try to probe each component by using alsa specific probe functions (alc5624_probe/das_probe/etc). The exact place where all those calls are done is when tegra_snd_shuttle_probe calls snd_soc_register_card(). If any probe function fails, the sound card is not registerred.

By placing some printks on all those functions, you can easily see the call sequence

And , yes, the 3.1 kernel allows to use a non fixed sampling rate. It will reprogram all clocks to get the expected sampling rate..

Link to comment
Share on other sites

Guest univall

I've been working on the huawei generic ril to make work better and with other huawei dongles.... It should support voice, but not all huawei modules support it ... For example, my e168 does not (at least, with the bundled firmware) ... Nevertheless, USSD calls, and normal call (no audio if no voice support in fw) work... Unfortunately, maybe i have broken data access .. As i have tried to copy what the original huawei supplied RIL did (it uses RNDIS instead of PPP...)... Well, i think it will require a little bit more of debugging, but i post it here for those of you who would like to try it... ;) -- Try voice call, try USSD, try sms, try Data connection ...

I tried with these files (replacing older huawei files) and with a freshly built rom including changes to build.prop and init.rc described in README in the archive.

- Not much has changed except that the signal to cell network seems to be more permanent and not going on or off in the taskbar as in the previous case.

- Still no audio over a phone call.

- No ring on called phone. Hanging up takes ages. Have to reboot to hang up/disconnect a call made from tablet to phone - call still not going through. No errors shown.

- No response/ring on tablet when phone calls tablet (can hear ring on phone - remains unanswered)

- No 3g/2g data.

Link to comment
Share on other sites

Guest ejtagle

I tried with these files (replacing older huawei files) and with a freshly built rom including changes to build.prop and init.rc described in README in the archive.

- Not much has changed except that the signal to cell network seems to be more permanent and not going on or off in the taskbar as in the previous case.

- Still no audio over a phone call.

- No ring on called phone. Hanging up takes ages. Have to reboot to hang up/disconnect a call made from tablet to phone - call still not going through. No errors shown.

- No response/ring on tablet when phone calls tablet (can hear ring on phone - remains unanswered)

- No 3g/2g data.

Regarding voice, check logcat -b radio

You are interested in the AT^VOICE command and its response. If it gives error, then your 3G modem does not support voice ... Not all huawei modems support voice, unfortunately... BTW, i was able to do calls and hang up communications without issue using this ril and an E169 dongle

Maybe the modem is being turned off when the tablet is suspended.,. You should get in the RIL log

+RING , when a call is being received...

Link to comment
Share on other sites

Guest univall

Regarding voice, check logcat -b radio

You are interested in the AT^VOICE command and its response. If it gives error, then your 3G modem does not support voice ... Not all huawei modems support voice, unfortunately... BTW, i was able to do calls and hang up communications without issue using this ril and an E169 dongle

Maybe the modem is being turned off when the tablet is suspended.,. You should get in the RIL log

+RING , when a call is being received...

Thank you for checking this out. Please see attached log, since I can't figure out what goes wrong here. AT^VOICE does not give an error, it says not found. I am on a Viewsonic 10s 3g internal modem. There is a perpetual cell signal in the taskbar. When tablet is called from a phone (pls see logs) the ring is recognized in the logs but no visual or audio indication is there on the tablet and the calling phone gets an unanswered message after some time. Also SMS cannot be sent or received. This was not the case with the earlier huawei files. Calls could be made and received along with ring tone and visual indication (phone ui) and sms could be sent or received. Only there was no audio through on the calls.

Edited by univall
Link to comment
Share on other sites

Guest ejtagle

Well, still working on RIL... The one posted below is able to originate and also answer calls, it is able to send sms, and uusds and should also be able to receive sms (untested, ran out of time)... Also, data connections should be working with it (also untested). Voice should work, but had no time to test it (the dongle i have right now does not support voice)..

huawei-generic-21aug.rar

Link to comment
Share on other sites

Guest univall

Well, still working on RIL... The one posted below is able to originate and also answer calls, it is able to send sms, and uusds and should also be able to receive sms (untested, ran out of time)... Also, data connections should be working with it (also untested). Voice should work, but had no time to test it (the dongle i have right now does not support voice)..

Tried this with a quick build and as you mention, sms sending and receiving is no issue, calling and receiving is not a problem, USSD code works. For me voice is not working and AT^VOICE does not give error but returns "not found".

And still no 3g out of the box. Does it have something to do with the changes in the README attached.

Will soon do a clean build and report back later.

One query: The attached README from the huawei-generic folder - is it the one you want to be followed or are there changes to it since this file has remained constant over different editions.

Thanks for your time.

Edited by univall
Link to comment
Share on other sites

Guest ejtagle

Tried this with a quick build and as you mention, sms sending and receiving is no issue, calling and receiving is not a problem, USSD code works. For me voice is not working and AT^VOICE does not give error but returns "not found".

And still no 3g out of the box. Does it have something to do with the changes in the README attached.

Will soon do a clean build and report back later.

One query: The attached README from the huawei-generic folder - is it the one you want to be followed or are there changes to it since this file has remained constant over different editions.

Thanks for your time.

I have slightly changed the 3g init sequence. Maybe that is the problem. I still have to debug it. Maybe i have introduced some bug in it. Please, if you can post logcat -b radio for the 3g enable, it would be great (hte only part i am interested should be between

"Identifying modem capabilities..."

and

"Data connection established!" or "Unable to setup PDP"

Also, related to voice, i am interested in the piece of the log between

AT^CVOICE=0

and "Audio Tunnel enabled" or "Failed to start audio tunnel"

I will try to get myself logs... ;)

edit1: Yes,m the README is pretty close to what you need. Don't forget the ppp scripts ;)

Edited by ejtagle
Link to comment
Share on other sites

Guest Scanno

I have slightly changed the 3g init sequence. Maybe that is the problem. I still have to debug it. Maybe i have introduced some bug in it. Please, if you can post logcat -b radio for the 3g enable, it would be great (hte only part i am interested should be between

"Identifying modem capabilities..."

and

"Data connection established!" or "Unable to setup PDP"

Also, related to voice, i am interested in the piece of the log between

AT^CVOICE=0

and "Audio Tunnel enabled" or "Failed to start audio tunnel"

I will try to get myself logs... ;)

Great to see some activity on the 3g part with some new help :D

Wish I could help a bit more.

Link to comment
Share on other sites

Guest Scanno

Tried this with a quick build and as you mention, sms sending and receiving is no issue, calling and receiving is not a problem, USSD code works. For me voice is not working and AT^VOICE does not give error but returns "not found".

And still no 3g out of the box. Does it have something to do with the changes in the README attached.

Will soon do a clean build and report back later.

One query: The attached README from the huawei-generic folder - is it the one you want to be followed or are there changes to it since this file has remained constant over different editions.

Thanks for your time.

If you are still using the device tree / manifest from my github, the PPP scripts and the things in the readme are already included. Some of the stuff s ramdisk related and they are already present in the ramdisk of the vegabean beta 1 kernel.

Link to comment
Share on other sites

Guest univall

I have slightly changed the 3g init sequence. Maybe that is the problem. I still have to debug it. Maybe i have introduced some bug in it. Please, if you can post logcat -b radio for the 3g enable, it would be great (hte only part i am interested should be between

"Identifying modem capabilities..."

and

"Data connection established!" or "Unable to setup PDP"

Also, related to voice, i am interested in the piece of the log between

AT^CVOICE=0

and "Audio Tunnel enabled" or "Failed to start audio tunnel"

I will try to get myself logs... ;)

edit1: Yes,m the README is pretty close to what you need. Don't forget the ppp scripts ;)

Please see attached logs. One that logs radio from boot to shutdown during which the cell network has connected signal indication has appeared (but no 3g). The second logs radio from the time a call is made from the tablet to a phone to the time it is ended without voice being heard on either side over the call. I could get you any more logs that you need, please let me know.

I have been checking this both with Scanno's Beta 1 ramdisk as well as one that i extracted from his Beta 1 boot.img and made sure that the init lines were there and repacked. These logs are with Scanno's Beta 1 boot.img/ramdisk.

The cell network connects almost immediately on boot, something that was not happening earlier.

Also, please note that the USSD code runs and tries to get a response but ends up with 'wrong MMI code or network not available' message on 2 networks. I am not sure that's a correct response as there is a valid output from these codes on another android phone.

logcat-ril-210861.txt

logcat-calling-210861.txt

Link to comment
Share on other sites

Guest univall

Great to see some activity on the 3g part with some new help :D

Wish I could help a bit more.

Thank you, Scanno for all your previous help and tutoring on this. Couldn't have been possible otherwise. Glad to be of help.

Link to comment
Share on other sites

Guest univall

If you are still using the device tree / manifest from my github, the PPP scripts and the things in the readme are already included. Some of the stuff s ramdisk related and they are already present in the ramdisk of the vegabean beta 1 kernel.

Yes, still using your device tree/manifest from your github. Thank you.

Link to comment
Share on other sites

Guest ejtagle

The RIL is properly connecting to the 3g network... the pppd daemon is failing to configure the connection

This signals successfull connection to the 3G network

D/AT ( 106): AT(12)> AT+CGDATA="PPP",1

I/AT ( 106): AT(12)< CONNECT

And this means the pppd daemon was unable to configure the ppp link...

E/RIL ( 106): Timeout waiting net.ppp0.local-ip - giving up!

E/RIL ( 106): Unable to setup PDP

Link to comment
Share on other sites

Guest univall

The RIL is properly connecting to the 3g network... the pppd daemon is failing to configure the connection

This signals successfull connection to the 3G network

D/AT ( 106): AT(12)> AT+CGDATA="PPP",1

I/AT ( 106): AT(12)< CONNECT

And this means the pppd daemon was unable to configure the ppp link...

E/RIL ( 106): Timeout waiting net.ppp0.local-ip - giving up!

E/RIL ( 106): Unable to setup PDP

Is it a permissions issue? What needs to be done?

Link to comment
Share on other sites

Guest Scanno

Is it a permissions issue? What needs to be done?

We should be looking at the PPP scripts. They are from vegacream where they were working. So there may be some changes needed to make this work for jellybean and the new ril.

Edited by Scanno
Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.