Jump to content
PaulOBrien

Advent Vega kernel source code now available!

Recommended Posts

We use i2c devices .. SPI is not used ... at least on shuttle. I think there is no need to enable all SPI channels... ;)

The out of memory errors were caused, at least with shuttle, because we were using a wrong block size ... We do get audio recordings, but they seem to be garbled... sometimes... :o .. We didn't get Out of memory errors with the latest audio_hw_primary i posted here. The Adam version is based on my previous version of audio_hw_primary that did not had those fixes... Unifying the sampling rate between capture and playback is needed (even the codec does not suport different sampling rates between play and record channels) ... I'd suggest to compare them and port the changes, as they are minimal ... ;)

We also modified our audio userspace lib as well, but the errors about DMA in dmesg and the out of memory errors were still occuring in logcat,

Our recording apps also 'appeared' to capture noise, but I suspect it is nothing but junk input caused by the failures to open the PCM device.

Once I removed a few SPI devices the recording was able to proceed error free, but I have yet to successfully receive any input from the microphone.

I am even able to switch the ADC into capturing the DAC output and record that in android applications, so I think I haven't enabled the microphone hardware fully yet...

Edited by DrMon

Share this post


Link to post
Share on other sites

We also modified our audio userspace lib as well, but the errors about DMA in dmesg and the out of memory errors were still occuring in logcat,

Our recording apps also 'appeared' to capture noise, but I suspect it is nothing but junk input caused by the failures to open the PCM device.

Once I removed a few SPI devices the recording was able to proceed error free, but I have yet to successfully receive any input from the microphone.

I am even able to switch the ADC into capturing the DAC output and record that in android applications, so I think I haven't enabled the microphone hardware fully yet...

Perhaps the mic bias ? --- If you are able to capture DAC output, as you say, seems to be something witht the codec or the mic ;)

BTW: I think this can be useful to us, the Shuttle people. I am sure the mic in our hw is properly initialized, so if must be what you found ;) - Thanks for sharing!

Edited by ejtagle

Share this post


Link to post
Share on other sites

We use i2c devices .. SPI is not used ... at least on shuttle. I think there is no need to enable all SPI channels... ;)

The out of memory errors were caused, at least with shuttle, because we were using a wrong block size ... We do get audio recordings, but they seem to be garbled... sometimes... :o .. We didn't get Out of memory errors with the latest audio_hw_primary i posted here. The Adam version is based on my previous version of audio_hw_primary that did not had those fixes... Unifying the sampling rate between capture and playback is needed (even the codec does not suport different sampling rates between play and record channels) ... I'd suggest to compare them and port the changes, as they are minimal ... ;)

Interestingly i just made some audio recordings and they sounded fine, way better then the previous kernel/test i tried .. ive not used many apps to test this out but from voice recorder on marketplace it did exactly what it said on the tin ....

Share this post


Link to post
Share on other sites

Eduardo,

I think we need to look to sleep again .. its not working ... Im loath to bring it up again just as im about to package up Alpha 3 and release it but after a day of seeing weird sleep issues i figured id better have a look some more ...

http://pastebin.com/cy1atAqD

That's just a log of devices not going to sleep ... my device is never unplugged long enough to really have noticed this plus been busy with other stuff, I was sure previously sleep was occurring rather then the screen just going off as wakeup time was taking a second or 2 and maybe a couple of button presses rather than instant display on ... It could be attributed to my removal of the always keep wifi on in sleep sys entry in the postboot file, same with BT ... Id need to look further ... but can you look to the log and see what you think ?

Same issue occurs with wifi on or off, sdcard in or out ... Actually the log looks very familiar to the problem we had before and resolved to get to sleep but to never return. I've not looked to the Adam code yet to see if their resolution now is same as what we have...

Cheers

Cass

Share this post


Link to post
Share on other sites

Eduardo,

I think we need to look to sleep again .. its not working ... Im loath to bring it up again just as im about to package up Alpha 3 and release it but after a day of seeing weird sleep issues i figured id better have a look some more ...

http://pastebin.com/cy1atAqD

That's just a log of devices not going to sleep ... my device is never unplugged long enough to really have noticed this plus been busy with other stuff, I was sure previously sleep was occurring rather then the screen just going off as wakeup time was taking a second or 2 and maybe a couple of button presses rather than instant display on ... It could be attributed to my removal of the always keep wifi on in sleep sys entry in the postboot file, same with BT ... Id need to look further ... but can you look to the log and see what you think ?

Same issue occurs with wifi on or off, sdcard in or out ... Actually the log looks very familiar to the problem we had before and resolved to get to sleep but to never return. I've not looked to the Adam code yet to see if their resolution now is same as what we have...

Cheers

Cass

Yes, you are right, Cass... This log seems very familiar to me ;)... The device is not entering suspend, as a wakelock is preventing it to enter... And the wakelock, i'd guess, is the mmc/sdhci wakelock. I did a patch to solve this issue for the .39 kernel, and i think that applying it to our new kernel will also fix the problem.. I will do the porting of the patch and post the resulting updated patch in a sec ;)

Andif you say mic is working... It would be nice to try an app that outputs audio at the same time that is records it... ;)

Share this post


Link to post
Share on other sites

Yes, you are right, Cass... This log seems very familiar to me ;)... The device is not entering suspend, as a wakelock is preventing it to enter... And the wakelock, i'd guess, is the mmc/sdhci wakelock. I did a patch to solve this issue for the .39 kernel, and i think that applying it to our new kernel will also fix the problem.. I will do the porting of the patch and post the resulting updated patch in a sec ;)

Andif you say mic is working... It would be nice to try an app that outputs audio at the same time that is records it... ;)

Nice one :)

Any suggestions for an app of that type ? i cant think of an app that both records audio and outputs it at the same time ... Actually im finding it hard at this hour to get my head around why anyone would ever need an app of that type ;)

Ill do soundhound, im sure that was a problem before ..

edit -- soundhoud is fine .. correctly identified the song i played it :)

edit2 -- well yeah it cant do both at same time .. when i cause kb clicks at same time its listening to song the song fails to be recognised ...

E/audio_hw_primary( 105): cannot open pcm_out driver: cannot open device '/dev/snd/pcmC0D0p': Out of memory

Edited by Cass67

Share this post


Link to post
Share on other sites

Nice one :)

Any suggestions for an app of that type ? i cant think of an app that both records audio and outputs it at the same time ... Actually im finding it hard at this hour to get my head around why anyone would ever need an app of that type ;)

Ill do soundhound, im sure that was a problem before ..

edit -- soundhoud is fine .. correctly identified the song i played it :)

edit2 -- well yeah it cant do both at same time .. when i cause kb clicks at same time its listening to song the song fails to be recognised ...

E/audio_hw_primary( 105): cannot open pcm_out driver: cannot open device '/dev/snd/pcmC0D0p': Out of memory

Well, DrMon was right after all... Fix is easy.. i will include it in the kernel patch ;)

edit: Patch attached: It includes 2 fixes:

1) I forward ported the wakelock handling of the 2.6.39 nvidia kernel as it seems superior to the one present on the rel14r7 version. It also includes the fixes required so it allows suspension of the device. To be exact, the rel14r7 uses a global wakelock shared between all instances of the mmc, and that seems not to be correct, as we have 2 instances of them: The wifi card and the external mmc. Theolder implementation has a separate wakelock for each instance, so it seems more correct. But, it also had bugs, so i had to fix them. The patch includes all those fixes.

It also includes the DrMon suggested fix to allow simultaneous playback and recording of sounds. The shuttle hw does not use the SPI peripherals of tegra, but those peripherals use valuable DMA channels. So, we won't register them, freeing them for other purposes, as audio io, for example :)

rel-14r7-shuttle support-11feb.rar

Edited by ejtagle

Share this post


Link to post
Share on other sites

Well, DrMon was right after all... Fix is easy.. i will include it in the kernel patch ;)

edit: Patch attached: It includes 2 fixes:

1) I forward ported the wakelock handling of the 2.6.39 nvidia kernel as it seems superior to the one present on the rel14r7 version. It also includes the fixes required so it allows suspension of the device. To be exact, the rel14r7 uses a global wakelock shared between all instances of the mmc, and that seems not to be correct, as we have 2 instances of them: The wifi card and the external mmc. Theolder implementation has a separate wakelock for each instance, so it seems more correct. But, it also had bugs, so i had to fix them. The patch includes all those fixes.

It also includes the DrMon suggested fix to allow simultaneous playback and recording of sounds. The shuttle hw does not use the SPI peripherals of tegra, but those peripherals use valuable DMA channels. So, we won't register them, freeing them for other purposes, as audio io, for example :)

<6>[ 65.210331] Entering suspend state LP1

W000t ... looks nice ... cracking job man .. thanks .... just need a longer test but this is looking awesome :) Ill test the audio out also :)

EDIT: -- You solved the sound issue too ... Soundhound finds the song i play it while i cause kb clicks .. outstanding ... Thanks Very much .. great job :) Alpha 3 by the looks of it now can be Beta 1 if my tests continue to be this great :D

Ill tip my hat to DrMon when i see him too :)

Edited by Cass67

Share this post


Link to post
Share on other sites

<6>[ 65.210331] Entering suspend state LP1

W000t ... looks nice ... cracking job man .. thanks .... just need a longer test but this is looking awesome :) Ill test the audio out also :)

EDIT: -- You solved the sound issue too ... Soundhound finds the song i play it while i cause kb clicks .. outstanding ... Thanks Very much .. great job :) Alpha 3 by the looks of it now can be Beta 1 if my tests continue to be this great :D

Ill tip my hat to DrMon when i see him too :)

:) -- B sure there will be issues... I would be interesting to include all fixes that went into Vegacomb...

The items i can remember right now:

1) The Bluetooth/wifi coexistance daemon from Atheros

2) HDMI full screen ..

3) HDMI audio... I don-t know if it works or not, but, Adam guys got it working using my audio lib, but they switched audio ports.. I don-t understand why.. I think theports were right...

4) The USB/host slave switch app

5) GPRS... DerArtem version libhuawei-generic-ril should work for us. I am currentlyinvestigating it ;)

But you are right, it it works good, probably it can be a beta. And i would suggest not to forget including the "Not for profit" Logo .. I am pretty sure the #### manufacturers will try to use this rom without crediting, and that is not fair at all. You have dedicated so much effort to it, that it makes sense to place that logo ;)

Share this post


Link to post
Share on other sites

:) -- B sure there will be issues... I would be interesting to include all fixes that went into Vegacomb...

The items i can remember right now:

1) The Bluetooth/wifi coexistance daemon from Atheros

2) HDMI full screen ..

3) HDMI audio... I don-t know if it works or not, but, Adam guys got it working using my audio lib, but they switched audio ports.. I don-t understand why.. I think theports were right...

4) The USB/host slave switch app

5) GPRS... DerArtem version libhuawei-generic-ril should work for us. I am currentlyinvestigating it ;)

But you are right, it it works good, probably it can be a beta. And i would suggest not to forget including the "Not for profit" Logo .. I am pretty sure the #### manufacturers will try to use this rom without crediting, and that is not fair at all. You have dedicated so much effort to it, that it makes sense to place that logo ;)

Yeah for sure there will be issues, i count on it from the users ;)

1) ill look into it .. but from memory and user feedback if im correct BT and wifi work as far as my limited tests go

2) Have the scale option already in build.prop and looks real nice if my 3 is correct :)

3) im sure it works already, think i watched netflix on my tv .. ill test again tomorrow as it may not have been this rom.

4) Already in place ;)

5) Great ... ill be ready to receive as im blind here ...

Wrt the the logo .. im kinda against it on principle but i will add one out of respect for the work done, and its not "I" have dedicated so much work, its "WE" ;) We would not be here now if it were not for your outstanding kernel coding .... id be porting everything to Pershoots .36 about now and wondering wtf pinmux and the like was all about ;)

Wifi is the last big issue i see right now .. its not playing ball at all ... works but wfter scanning and finding an AP it sort of gives up after passwd is input and you have to power off/on wifi to get another shot .. manually adding AP apparently works around this but im looking to the Android side for this .. spent a fair bit of time on this for no real gain ...

Cass

Edited by Cass67

Share this post


Link to post
Share on other sites

Well done lads, cant wait for the beta.

couple of beers on the way to you.

Thanks for your hard work.

You have dedicated so much effort to it, that it makes sense to place that logo ;)

Definitely! its a small price to pay for all your hard work. Something a bit more pleasing to the eye would be nice though, the bright white background of the one in vegacomb was very harsh on the eye. Especially if you are using it in the dark and have to reboot.

Edited by richardmlea

Share this post


Link to post
Share on other sites

Well done lads, cant wait for the beta.

couple of beers on the way to you.

Thanks for your hard work.

Definitely! its a small price to pay for all your hard work. Something a bit more pleasing to the eye would be nice, the bright white background of the one in vegacomb was very harsh on the eye.

I would not be surprised if the Shuttle people take this rom to promote their sales.. Yes, even if i also don't like the logo , i think we should include it. Perhaps, using a black background instead of white, would be more than enough to make it acceptable ;) .. There is no need to tell that perhaps the user has been ripped off.. Just saying something about the rom, that it is the effort of a community (Cass!) and that it should not be used to charge extra money for the device, should be enough ;)

Share this post


Link to post
Share on other sites

Well done lads, cant wait for the beta.

couple of beers on the way to you.

Thanks for your hard work.

Definitely! its a small price to pay for all your hard work. Something a bit more pleasing to the eye would be nice though, the bright white background of the one in vegacomb was very harsh on the eye. Especially if you are using it in the dark and have to reboot.

What? your adverse to my putting a bright flashing strobe effect splash and forcing rock music a full volume through your speakers on boot .. tsk tsk :)

Share this post


Link to post
Share on other sites

I would not be surprised if the Shuttle people take this rom to promote their sales.. Yes, even if i also don't like the logo , i think we should include it. Perhaps, using a black background instead of white, would be more than enough to make it acceptable ;) .. There is no need to tell that perhaps the user has been ripped off.. Just saying something about the rom, that it is the effort of a community (Cass!) and that it should not be used to charge extra money for the device, should be enough ;)

Those pesky shuttle dudes ... always up to something :)

Share this post


Link to post
Share on other sites

REgarding the BT/Wifi daemon (btmon), it is required to make A2DP and wifi work at the same time without getting bluetooth audio drops... A2DP bluetooth profile is the problem. All the other bt profiles will work without it,

Regarding Wifi, perhaps Android logs would give us a hint on what it is happening... Perhaps it is an incompatibility between Atheros driver and Android. I am pretty sure it can be fixed, if that is the problem ;)

On a sidenote, this is the AT command specification of the Huawei module ...

ES90_AT_COMMANDS_MANUAL_V18.pdf

Share this post


Link to post
Share on other sites

REgarding the BT/Wifi daemon (btmon), it is required to make A2DP and wifi work at the same time without getting bluetooth audio drops... A2DP bluetooth profile is the problem. All the other bt profiles will work without it,

Regarding Wifi, perhaps Android logs would give us a hint on what it is happening... Perhaps it is an incompatibility between Atheros driver and Android. I am pretty sure it can be fixed, if that is the problem ;)

On a sidenote, this is the AT command specification of the Huawei module ...

nice ... check your PM mate !

Android logs show not much ... the radio logcat shows stuff regarding the ril and wifi changing state but its not verbose enough to tell for sure if thats the cause .... all we see in normal logs is scanning msgs ...

Share this post


Link to post
Share on other sites

nice ... check your PM mate !

Android logs show not much ... the radio logcat shows stuff regarding the ril and wifi changing state but its not verbose enough to tell for sure if thats the cause .... all we see in normal logs is scanning msgs ...

KErnel logs could also help here ;)

Share this post


Link to post
Share on other sites

Whaty about HDMI audio ? -- Did it work ? -- Seems that if it does not, the required mods to make it work are trivial... I will try to test it, but feel free to also test it and tell me if it does not work ;), so we can fix it

HDMI audio does not work .. pure unadulterated silence :(

I/ActivityManager( 157): START {cmp=com.netflix.mediaclient/.PlayerActivityPlus (has extras)} from pid 2041

--------- beginning of /dev/log/main

D/audio_hw_primary( 95): start_output_stream: card:1, port:0, rate:44100

E/audio_hw_primary( 95): cannot open pcm_out driver: cannot open device '/dev/snd/pcmC1D0p': No such file or directory

spam goes on :)

Cass

Share this post


Link to post
Share on other sites

HDMI audio does not work .. pure unadulterated silence :(

I/ActivityManager( 157): START {cmp=com.netflix.mediaclient/.PlayerActivityPlus (has extras)} from pid 2041

--------- beginning of /dev/log/main

D/audio_hw_primary( 95): start_output_stream: card:1, port:0, rate:44100

E/audio_hw_primary( 95): cannot open pcm_out driver: cannot open device '/dev/snd/pcmC1D0p': No such file or directory

spam goes on :)

Cass

I think you are using an older version of the library... card:1 is an invalid and impossible value on the latest one... For HDMI, you should get card:0, port: 2,,, Just in case, attached the latest audio_hw_primary ... it must be compiled inside AOSP...

And the compiled version... Make sure to rename it if required to match your board name...

audio_v3.rar

audio.primary.shuttle.rar

Edited by ejtagle

Share this post


Link to post
Share on other sites

I think you are using an older version of the library... card:1 is an invalid and impossible value on the latest one... For HDMI, you should get card:0, port: 2,,, Just in case, attached the latest audio_hw_primary ... it must be compiled inside AOSP...

Ohh ok .. cool :) Ill check it out in the morning and let you know how i get on .. 4am here and i dont want to build another lib ;) check your pm . i responded ..

Share this post


Link to post
Share on other sites

Ohh ok .. cool :) Ill check it out in the morning and let you know how i get on .. 4am here and i dont want to build another lib ;) check your pm . i responded ..

No problems ;)

Share this post


Link to post
Share on other sites

No problems ;)

Heh, cheers .. i see the compiled version now .. but its mainly i cant be assed right now unsquashing lib and reflashing a new system ... that was the lib i refered to ;)

Share this post


Link to post
Share on other sites

Heh, cheers .. i see the compiled version now .. but its mainly i cant be assed right now unsquashing lib and reflashing a new system ... that was the lib i refered to ;)

No problems.. There's no hurry on this. Better to take all the required time to make sure it works ;)

Share this post


Link to post
Share on other sites

I think you are using an older version of the library... card:1 is an invalid and impossible value on the latest one... For HDMI, you should get card:0, port: 2,,, Just in case, attached the latest audio_hw_primary ... it must be compiled inside AOSP...

And the compiled version... Make sure to rename it if required to match your board name...

Yep .. the compiled and the source lib does indeed give sound ... nice one ... BUT .... and there sadly always is a but ... the video seems to slow down when its viewed over HDMI ... the sound is sloooow, talking sounds like a movie where something bad is about to happen and they go running towards the victim and shout noooooooooooo in a way thats never ever going to result in something good happening ;)

http://pastebin.com/FD8FJR96

EDIT - ok seems fixed now ... seems changing sampling rate to 48000 for SPDIF resolves the problem, sound and video is as we'd expect it to be ..

#define MM_SPDIF_SAMPLING_RATE 48000

See anything adverse with doing this ?

edit 2 -- all appears fine --- Alpha3 has been released here

Cheers

Cass

Edited by Cass67
  • Upvote 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

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