[07:26] <III> has anyone used/tried displaylink on 10.10?
[08:38] <hrw> morning
[08:50] <sebjan> lag: panda OTG port: yes it does work, but not as OTG, it is configured as device in the kernel config
[08:52] <lag> sebjan: So what do you make of bug 645420
[08:52] <ubot2> Launchpad bug 645420 in linux-ti-omap4 (Ubuntu) "OTG port not enabled for OMAP4 (affects: 2) (heat: 324)" [Low,Confirmed] https://launchpad.net/bugs/645420
[08:54] <sebjan> lag: well, I already commented on this bug: our driver is not OTG capable at the moment, this is why it is statically configured as device. It is working fine as device.
[08:54] <sebjan> lag: this will not change for 10.10. I think we shall have the driver fixed to support OTG in 11.04.
[09:00] <lag> sebjan: So you did
[13:48] <lag> sebjan: I've just read your comment on the audio bug
[14:01] <cooloney> lag: me2
[14:01] <cooloney> heh
[14:01] <cooloney> sebjan: ogra_ac and i think the default.pa is the same as ogra_ac posted in the launchpad.
[14:02] <davidm> cooloney, how did things go yesterday?
[14:02] <ogra_ac> well, at least the one you pasted before
[14:02] <ogra_ac> davidm, well, network is still super slow
[14:03] <davidm> did uboot and xloader get changed?
[14:03] <ogra_ac> rsalveti has a package ready i think
[14:03] <ogra_ac> uboot doesnt need changes
[14:03] <ogra_ac> and i think i worked out a proper solution of the mixer settings
[14:03] <sebjan> cooloney, ogra_ac: ok, I did not check that, I retrieved the default.pa delivered from our dev team, and saw it was different from the one installed by default in the daily images, so updated it
[14:03] <ogra_ac> (which at least solves 50% of the audio prob)
[14:04] <rsalveti> yup
[14:04] <rsalveti> let's test soon :-)
[14:04] <ogra_ac> sebjan, we cant change default.pa
[14:04] <lag> I'm still unsure what progress has been made on the audio since I worked on it
[14:04] <ogra_ac> using that file would break audio for everyone but panda users
[14:04] <lag> ALSA has always worked with only the amixer settings
[14:04] <ogra_ac> sebjan, but i have an idea for the mixer which i'll test today
[14:05] <sebjan> ogra_ac: yep, this was just to check the drivers are able to generate some sound. This is not the final solution.
[14:05] <lag> Pulse has never worked
[14:05] <lag> The card is only reported when the other config file is used
[14:05] <ogra_ac> lag, alsa has never worked without modifying the default volumes
[14:05] <lag> What's new? What's different?
[14:05] <lag> Correct
[14:05] <lag> So what's new?
[14:05] <cooloney> sebjan: yeah, we think sound driver works, but maybe the route setting has some issue
[14:05] <ogra_ac> thast what the mixer settings are for :P
[14:05] <ogra_ac> lag, that we needed a proper way to set them
[14:06] <lag> I've heard lots of people talk about it being better and there are patches and improvements have been made, but I see no difference to 2 weeks ago
[14:06] <sebjan> cooloney: yes, that shall be the purpose of SDP4430.conf file to setup the proper routings
[14:06] <ogra_ac> which i think i found (need to test later today, its early here)
[14:06] <lag> ogra_ac: What are the proper way?
[14:06] <ogra_ac> sebjan, why cant we fix the routings in the driver
[14:06] <lag> I can probably do it in the kernel
[14:06] <lag> (which is what I'v been looking at)
[14:07] <ogra_ac> lag, i doubt that since it needs to be modifyable per device
[14:07] <lag> ogra_ac: How do you mean?
[14:07] <ogra_ac> lag, /usr/share/alsa/init/hda is a good example
[14:07] <ogra_ac> lag, blaze and panda need different volume adjustments (and later devices probably too)
[14:08] <lag> ogra_ac: Okay
[14:08] <ogra_ac> lag, the more important part is the routing
[14:08] <sebjan> ogra_ac: don't know, I did not follow up on this topic, I repeat what I understood from berco :)
[14:08] <ogra_ac> whioch is wrong in kernel
[14:08] <ogra_ac> cooloney worked on a fix for that
[14:08] <ogra_ac> but we havent tested
[14:08] <ogra_ac> (in the driver)
[14:08] <lag> What's the fix?
[14:08] <ogra_ac> switching the routing of device 0
[14:09] <lag> THIS is why I needed to speak to cooloney yesterday!
[14:09] <rsalveti> if we had a proper network :-)
[14:09] <cooloney> we can play sound over device 7 via speaker-test after some alsamixer setting
[14:09] <ogra_ac> btw, ES2.1 boots fine
[14:09] <cooloney> but pluseaudio will open device 0, which will fail
[14:09] <lag> ogra_ac managed - rsalveti managed
[14:09] <cooloney> and PA never runs
[14:09] <ogra_ac> lag, managed ?
[14:09] <lag> I even saw cooloney log on, only to log off again 15 mins later
[14:09] <lag> To get online
[14:10] <ogra_ac> lag, well, FSVO online
[14:10] <lag> comradekingu: What's device 7 currently?
[14:10] <ogra_ac> the network at TI is really bad
[14:10] <lag> FSVO?
[14:10] <ogra_ac> for some value of
[14:10] <lag> How do they manage?
[14:10] <ogra_ac> (you know, you use these abbreviations to not have to type so much :P)
[14:10] <ogra_ac> lag, i was on through 3G
[14:11] <lag> YMTUY
[14:11] <rsalveti> shared 3g, the only one that worked
[14:11] <lag> That sucks!
[14:11] <cooloney> lag: oh, from the my post in the launchpad, it is here http://pastebin.ubuntu.com/503799/
[14:11] <cooloney> lag: sorry, it should be device 9
[14:12] <lag> We've been able to play sound via HDMI from the beginning
[14:12] <cooloney> and sebjan i believe your alsamixer.sh can setup the right value of all the mixer
[14:12] <cooloney> then we can play our sound over device 9
[14:12] <ogra_ac> right, we just need to translate it into an alsa init file
[14:13] <sebjan> right, I think so
[14:13] <cooloney> but device 0, there is no-codec-associated
[14:13] <cooloney> pa try to open this default device 0, but failed
[14:13] <ogra_ac> so re-mapping the codec in the driver should fix that
[14:14] <cooloney> ogra_ac: yeah, we need to talk with audio expert from TI, this sdp4430.c ASoC driver is from their
[14:15] <ogra_ac> right
[14:48] <cooloney> sebjan: for your testing with modification of default.pa, you got sound from hdmi or headset?
[14:48] <sebjan> cooloney: I only tested headset
[14:50] <cooloney> sebjan: ok, got it. i will test it soon. we try to find a fix today.
[14:51] <cooloney> sebjan: i am going to push out the audio fixing patches today, since we are closed to 10.10 release
[14:51] <cooloney> sebjan: is there any other audio new fixings?
[14:52] <davidm> ogra_ac, if we only need xloader changes I'd like to see the patch diff between ES2.0 and ES2.1 silicon so I can get a feel of what is being done
[14:52] <sebjan> cooloney: ok. I received a 1 line patch update for audio that is supposed to help for the audio record. I'll send it to you right now. However I have not been able to make audio record even with it - we are still missing something here (maybe also a routing issue?)
[14:53] <cooloney> sebjan: oh, we never try recording i think, before we fix the playback.
[14:53] <ogra_ac> davidm, robclark is doing last tests
[14:53] <cooloney> sebjan: ok, please post me the audio patch
[14:54] <ogra_ac> davidm, if we get his ok (which i expect durign the day) we are good to go
[14:54] <ogra_ac> davidm, and we're all actively working on the sound issues
[14:54] <ogra_ac> davidm, for which we need a libalsa0 upload
[14:55] <ogra_ac> and possibly a kernel
[14:55] <ogra_ac> thats the three packages we'll need today
[14:56] <davidm> ogra_ac, I want to understand the "amount" of change between ES2.0 and ES2.1 so I can get a feel for the level of risk with releasing on 10.10
[14:56] <ogra_ac> davidm, about 30-40 lines in x-loader to handle the different ram speed
[14:56] <sebjan> cooloney: I just sent the audio patch
[14:57] <cooloney> sebjan: cool, thx
[15:01] <rsalveti> davidm: ogra_ac: yep, just different timmings to support ddr@400mhz
[15:01] <rsalveti> so it should work without breaking other stuff
[15:01] <rsalveti> but rob is giving some more tests
[15:04] <mpoirier> cooloney: moving the elements in the list of DAIs could fix the missing codec on the default device.
[15:04] <kornel`> hey
[15:04] <mpoirier> TI sound people would have to be consulted.
[15:05] <kornel`> does anyone know a board that has an arm processor and an ethernet interface? nothing else is needed, though its not a problem, but i need this to be as small as possible.
[15:05] <kornel`> and of course has the capability to run ubuntu oni t
[15:13] <GrueMaster> kornel`: Try beagleXM or Gumstix.
[15:13] <cooloney> mpoirier: cool. could you post me a patch?
[15:13] <mpoirier> cooloney: I don't have a patch for that...
[15:13] <cooloney> mpoirier: we are leaving from hotel to TI office
[15:13] <mpoirier> cooloney: ok hookup with me when you get on again
[15:22] <mopdenacker> ogra_ac:  Hi! We need to modify the pre-installed images to have custom boot.scr scripts for our internal releases. How would you do this, please?
[15:23] <ogra_ac> by a script
[15:23] <ogra_ac> mopdenacker, we need to head over to the office, lets talk in a few mins
[15:24] <mopdenacker> ogra_ac: we could also modify the script that creates the boot.scr file for the second boot... This way users wouldn't have to make any manual change...
[15:25] <mopdenacker> ogra_ac: no problemo. Thanks for your answer!
[15:26] <kornel`> thnx
[15:53] <sebjan> ogra_ac, cooloney: though the kernel was changed to allow 1GB usage without crash issues, the boot.scr cmd lines still restricts to 460 + 256M
[15:53] <cooloney> sebjan, yeah, good point,
[15:54] <ogra_ac> sebjan, yeah, i'll change that today
[15:54] <cooloney> ogra_ac, cool
[16:08] <mopdenacker> ogra_ac: back to my question... Our need is to modify the script that generates boot.scr after expanding the SD card partition. What file should we modify? That's only for our internal releases.
[16:26] <lag> ogra_ac: Can I close my half of bug 628029?
[16:26] <ubot2> Launchpad bug 628029 in linux-ti-omap4 (Ubuntu Maverick) (and 2 other projects) "[maverick] panda omap4 does not suspend (affects: 1) (heat: 8)" [High,Confirmed] https://launchpad.net/bugs/628029
[16:37] <lag> mopdenacker: If I'm not mistaken, I think you're looking for: /usr/share/initramfs-tools/scripts/local-bottom/jasper_setup
[16:50] <mopdenacker> lag: thanks a lot! I will take a look.
[16:50] <lag> mopdenacker: Any time :)
[16:52] <lag> sakoman: Good morning
[16:52] <sakoman> gm lag
[16:54] <lag> sakoman: Have you managed to find the time to push this upstream yet?
[16:54] <lag> sakoman: http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux-omap-2.6.git;a=commit;h=9f40ee61034576e8abdb8201c9526204680e70d5
[16:54] <sakoman> lag, no not yet
[16:55] <lag> sakoman: Any view to?
[16:57] <sakoman> lag: I'll be working on a patch series over the next couple of weeks.  I'll try to add it as part of that
[16:57] <lag> sakoman: Sounds good - thanks :)
[17:02] <kornel`> bye
[17:24] <sbambrough> https://wiki.canonical.com/UbuntuPlatform/ARM/LinaroCoordinationCallMinutes
[17:40] <berco1> is there a mean to install a specific version of a package? Using one omap4 cdimage, I have alsa-utils=1.0.23-2ubuntu1 and in a more recent img I have alsa-utils=1.0.23-2ubuntu3...
[17:40] <berco1> I want to be able to revert as I suspect an issue with latest version
[17:41] <berco1> apt-get install cannot find the alsa-utils-1.0.23-2ubuntu1 version...
[17:41] <berco1> are the old packages removed from cannonical archive?
[18:08] <cooloney> berco1, ogra_ac might can help to answer that.
[18:08] <cooloney> berco1, i am working on the audio issue in kernel side
[18:09] <berco1> cooloney: I think I found out myself  :)
[18:09] <berco1> cooloney: I found one on Launchpad https://launchpad.net/ubuntu/+source/alsa-utils/1.0.23-2ubuntu1/+build/1879590/+files/alsa-utils_1.0.23-2ubuntu1_armel.deb
[18:09] <cooloney> berco1, cool
[18:09] <berco1> cooloney: I have one image that has audio working with that famous SDP4430.conf file
[18:10] <berco1> cooloney: however, taking today's cdimage and putting the SDP4430.conf in it doesn't enable sound
[18:10] <cooloney> berco1, from the code in sound/soc/omap/sdp4430.c, the frondend dai-links are no codec associated, right?
[18:10] <berco1> cooloney: I found that alsa-utils, alsa-base and pulseaudio have been upgraded
[18:11] <cooloney> berco1, so from my side, the PulseAudio will fail due to failing to open the pcm0 device which is MultiMedia of SDP4430
[18:11] <berco1> cooloney: I need to check with audio dev team for your question
[18:11] <berco1> is that holding you?
[18:12] <cooloney> berco1, do you need to modify the default.pa to make the sound work?
[18:12] <berco1> cooloney: have you tried running the amixer.sh file?
[18:12] <berco1> cooloney: in my working setup, no default.pa change, I just use the default file
[18:12] <cooloney> berco1, yeah, i tried that. amixer.sh will set the right value
[18:13] <cooloney> berco1, cool. since modification of default.pa is not acceptable, that might make other omap4 based board sound broken
[18:14] <cooloney> berco1, sorry, need to have luch
[18:14] <berco1> cooloney: yes. Nevertheless, I still need to understand if it is one of the s/w upgrade that breaks my setup
[18:14] <cooloney> lunch, siya
[18:14] <berco1> see ya
[18:28] <mpoirier> cooloney: get in touch with me when you get back - we'll talk about your pmc0 device.
[19:02] <cooloney> mpoirier, hey, man. I am back from lunch
[19:02] <mpoirier> ok good.
[19:03] <mpoirier> you are correct, the default front end in the list doesn't have a codec.
[19:03] <mpoirier> actually it is set to the null-codec.
[19:04] <cooloney> mpoirier, right, that's why pulseaudio will fail to open the device.
[19:04] <mpoirier> if you were to put DAI entry pertaining to the headset at the very top of DAI list, I think that devices would become your default device.
[19:04] <mpoirier> that is, in theory, great...
[19:05] <mpoirier> but that DAI still wouldn't have any backend associated to it, resulting in a failure to open pcm0.
[19:05] <mpoirier> that's what lies at the heart of the problem.
[19:06] <cooloney> mpoirier, right. we are thinking in the same way
[19:06] <mpoirier> this is a config that is left to userspace, on purpose.
[19:06] <cooloney> mpoirier, i just fixed the first frontend dai-link
[19:07] <cooloney> built the kernel and will test soon
[19:07] <mpoirier> you prept it up in the list ?
[19:28] <ogra_ac> yay
[19:28] <ogra_ac> mixer defaults solved
[19:42] <cooloney> mpoirier, i found we need to debug the alsa and asoc code for a while
[19:43] <cooloney> maybe it is right that pcm0 doesn't have the codec driver associated
[19:43] <cooloney> it will be connected to a backend when we open it for operation at runtime
[19:43] <cooloney> but we failed to find one.
[19:43] <cooloney> so i am looking at this
[20:08] <rsalveti> GrueMaster: http://people.canonical.com/~rsalveti/maverick/boot/es21/MLO
[20:26] <mpoirier> cooloney: I'm back from lunch.
[20:27] <mpoirier> I have done a lot of tracing in the soc area...
[20:28] <mpoirier> hold on a sec...
[20:30] <mpoirier> did you see the latest addition from ogra ?
[20:32] <mpoirier> cooloney: did you see the latest finding from ogra ?
[20:32] <mpoirier> cooloney: about /usr/share/alsa/init/00main ?
[20:34] <cooloney> mpoirier, yeah, but that's for alsamixer. pulseaudio need to open it in the right way
[20:35] <mpoirier> cooloney: indeed, there are multiple part of the puzzle.
[20:35] <mpoirier> cooloney: take a look at this: http://omappedia.org/images/c/c9/OMAP4_Audio_Phoenix.jpg
[20:36] <mpoirier> cooloney: on the right hand side you have the famous DAIs.
[20:36] <mpoirier> cooloney: on the left side, second square, are the "interface".
[20:37] <mpoirier> cooloney: the famous PDMs. UL0, UL1, DL0...DL4
[20:39] <mpoirier> running the script omap4_amixer_config.sh will link the DAIs to the PDMs.
[20:40] <mpoirier> cooloney: it is only when that relashion is established that opening pcm0 can succeed.
[20:40] <mpoirier> cooloney: I spent a lot of time in there.
[20:42] <mpoirier> To the best of my knowledge, SDP4030.conf under /usr/share/alsa/cards/ is supposed to do that
[20:42] <mpoirier> sorry, SDP4430.conf.
[20:42] <mpoirier> TI guys are all very fluent with those concepts.
[20:42] <sguiriec> mpoirier:cooloney: I can support on this if you have trouble. Berco is still working on the finalization of SDP4430.conf file
[20:43] <mpoirier> sguiriec: the above is a recollection of 2 weeks of soul searching in the soc subsystem.
[20:44] <mpoirier> feel free to rectify anything that would not be accurate.
[20:46] <mpoirier> sguiriec: am I correct when saying that PDMs and DAIs are linked in file SDP4430.conf ?
[20:46] <sguiriec> mpoirier:You statement is ok. Final solution will be with SDP4430.conf file. With this file we should get ride of omap4_amixer_config.sh.
[20:47] <mpoirier> cooloney: hence no changes should be required to the kernel.
[20:47] <mpoirier> cooloney: at least that's the conclusion I came up with.
[20:48] <mpoirier> cooloney: all the ingredient in the kernel are there and working.  The scheme was meant to be generic.
[20:48] <sguiriec> mpoirier: Inside OMAP4 McPDM port include part of Sigma delta. This is why code is a little bit different form standard CODEC interface
[20:49] <mpoirier> sguiriec: the famous McPDMs... I'm still having a lot of fun with those.
[20:49] <cooloney> sguiriec, and mpoirier let me to report my findings here
[20:49] <mpoirier> cooloney: everybody should be on the same page on your side....
[20:50] <cooloney> speaker-test -D plughw:0,3 -t sine -c 2
[20:50] <cooloney> will generate sound
[20:50] <mpoirier> We've all talked about it in great lenght
[20:50] <sguiriec> mpoirier: Liam has work to get correct board name in order to have ALSA utils to be able to load SDP4430.conf file. Now we are finalizing the content of this file in order to set correctly the audio path after board boot.
[20:50] <cooloney> also 0,7
[20:51] <cooloney> the dynamically run time binding, looks right
[20:51] <cooloney> but device 0,0 doesn't generate any sound
[20:51] <sguiriec> mpoirier:cooloney: 0
[20:52] <cooloney> i can open it, the dmesg from driver tells me it binds to the right codec and backend
[20:52] <rsalveti> ogra: https://code.edge.launchpad.net/~rsalveti/ubuntu/maverick/x-loader-omap4/es21/
[20:52] <mpoirier> cooloney:  yes indeed, but your path to the PDM probably doesn't exist.
[20:53] <cooloney> mpoirier, so we need to check the bug in this binding thing
[20:53] <sguiriec> mpoirier:cooleney: can you check amixer controls for DL1 Media Playback Volume?
[20:55] <mpoirier> sguiriec: I'll have to fire up my board - what are you after ?
[20:56] <sguiriec> mpoirier:Inside ABE you have SW volume. Just want to check that volume is well set.
[20:56] <cooloney> sguiriec, let me check this.
[20:56] <mpoirier> cooloney: please, I don't have the very latest patch.
[20:57] <cooloney> sguiriec, my bad, i need to run the amixer.sh from sebjan and becor,
[20:58] <cooloney> sguiriec, i got sound from device 0,0
[20:59] <mpoirier> sguiriec: what state do you want the system to be in ?
[20:59] <mpoirier> sguiriec: just after booting ?
[21:00] <cooloney> sguiriec, i will try ogra's latest alsa config method to get alsamixer works firstly
[21:00] <cooloney> sguiriec, but we need to make the pulseaudio also working
[21:00] <sguiriec> mpoirier: cooloney:Until we finalise the SDP4430.conf file it is beter to run amixer.sh file (or omap4_amixer_setup). amixer.sh -a should reconfigure the audio path. Until it is not fix you will have no sound after boot
[21:01] <mpoirier> sguiriec: that is well understood on my side.
[21:01] <mpoirier> sguiriec: do you still want us to check DL1 Media playback ?
[21:01] <ogra> thats nothng we can do in the image
[21:01]  * ogra can only repeat that every time this comes up
[21:01] <ogra> uploas deadline for maverick is in a few hours
[21:02] <sguiriec> mpoirier: Yes if you have no audio on plughw:0,0 and audio on plughw:0,3 it should be linked to this control.
[21:02] <mpoirier> sguiriec: I'm here to provide you data - my board is powered up.
[21:03] <mpoirier> I haven't done anything to it so far, aka defautl value.
[21:03] <mpoirier> do yo want the value of DL1 now or after running amixer.sh ?
[21:04] <sguiriec> mpoirier: In case you have no audio it will be good to have it now and the to set up in the middle of the play
[21:04] <mpoirier> sguiriec: I definitely don't have audio right now.
[21:05] <sguiriec> mpoirier: Normally audio should come back if you run amixer.sh -a
[21:05] <mpoirier> sguiriec: indeed.
[21:05] <mpoirier> sguiriec: I'll run the script, hang on.
[21:05] <cooloney> sguiriec, amixer.sh is not a final solution for our release, i think ogra has make all the setting in his alsa init file.
[21:06] <ogra> which isnt proper either
[21:06] <ogra> SDP4430.conf is actually the right way to go
[21:08] <sguiriec> mpoirier:cooloney:Inline with this statement. berco is working on it. Seem to have trouble with Pulse and alsa versions.
[21:09] <mpoirier> sguiriec: indeed, berco was asking about older versions earlier today.  Is the newer stuff broken ?
[21:09] <sguiriec> mpoirier:cooloney: generation of asound.state file was not always inline with SDP4430.conf file. Newer stuff has broken it. This is why berco is asking older version
[21:11] <sguiriec> mpoirier:cooloney: I was just with him before coming back to home. Now need to understand what is borken and to see if it is inside pulse or alsa.
[21:13] <mpoirier> speaker-test -D plughw:0,3 -t sine -c 2
[21:13] <mpoirier> speaker-test -D plughw:0,7 -t sine -c 2
[21:14] <mpoirier> sorry, wrong console, please ignore
[21:15] <mpoirier> sguiriec: numid=3,iface=MIXER,name='DL1 Voice Playback Volume'
[21:15] <mpoirier>   ; type=INTEGER,access=rw---R--,values=1,min=0,max=149,step=0
[21:15] <mpoirier>   : values=110
[21:15] <mpoirier>   | dBscale-min=-120.00dB,step=1.00dB,mute=1
[21:15] <mpoirier> sguiriec: that is after running amixer.sh
[21:16] <mpoirier> sguiriec: speaker-test -D plughw:0,3 -t sine -c 2 works properly.
[21:17] <sguiriec> mpoirier: this control is for voice so plughw:0,2. DL1 Media Playback Volume should be numid=1
[21:18] <sguiriec> mpoirier: this control is for Voice port (plughw:0,2). For multimedia it should be numid=1 name='DL1 Media Playback Volume'
[21:19] <mpoirier> sguiriec: ok, one sec.
[21:20] <mpoirier> numid=1,iface=MIXER,name='DL1 Media Playback Volume'
[21:20] <mpoirier>   ; type=INTEGER,access=rw---R--,values=1,min=0,max=149,step=0
[21:20] <mpoirier>   : values=110
[21:20] <mpoirier>   | dBscale-min=-120.00dB,step=1.00dB,mute=1
[21:20] <mpoirier> sguiriec: ^^^^^^^^
[21:22] <sguiriec> mpoirier: Ok 110 looks ok. it means -10 dB. Can you check also numid=18? Should be the next gain in the ABE chain before headset. I will recommend to set it to 120 (0 dB).
[21:23] <mpoirier> sguiriec: numid=18,iface=MIXER,name='SDT DL Volume'
[21:23] <mpoirier>   ; type=INTEGER,access=rw---R--,values=1,min=0,max=149,step=0
[21:23] <mpoirier>   : values=120
[21:23] <mpoirier>   | dBscale-min=-120.00dB,step=1.00dB,mute=1
[21:23] <mpoirier> it is indeed set to 120.
[21:24] <sguiriec> mpoirier: And still not sound on headset
[21:24] <mpoirier> sguiriec: speaker-test -D plughw:0,3 -t sine -c 2 did work
[21:25] <mpoirier> sguiriec: so does speaker-test -D plughw:0,2 -t sine -c 2
[21:25] <sguiriec> mpoirier:depend on the controls.
[21:26] <mpoirier> sguiriec: we may be out of sync here...
[21:27] <cooloney> sguiriec and mpoirier, let me sync with you guys
[21:28] <cooloney> kernel driver looks ok, it uses the front end and back end for dynamically run time binding
[21:28] <cooloney> for alsamixer, we need SDP4430.conf and the script file to set it in right volumn
[21:29] <cooloney> moreover, we need to modify the default.pa of pulseaudio to make the sound works finally
[21:29] <sguiriec> mpoirier:cooloney: Yes you need to have a valid root between FE and BE. SPD4430.conf should do it after the boot
[21:30] <mpoirier> sguiriec: would you like me to run other tests ?
[21:30] <sguiriec> mpoirrier:cooloney: for pulse I am not the good guy to comment. May be in the comming weeks.
[21:30] <cooloney> but unfortunately, ogra said, we cannot modify the default.pa, since that will break other boards with different audio configuration
[21:31] <cooloney> anyway, guys, i am going to send out the audio patches
[21:31] <mpoirier> cooloney: I did not investigate the pulse front.
[21:31] <sguiriec> mpoirier: Just try on plughw:0,0. Normally you should have some sound
[21:31] <mpoirier> cooloney: too busy getting grey hair with PDMs and DAIs.
[21:31] <mpoirier> sguiriec: ok, one sec.
[21:32] <ndec> ogra: mpoirier: cooloney: hi!
[21:32] <ndec> so it looks better on the audio front...
[21:32] <sguiriec> mpoirier:cooloney: Just thinking that for pulse a patch has been already pull in 10.10 in order to set custom configuration on top of default.pa file.
[21:33] <ndec> sguiriec: no this was not pulled on time for 10.10
[21:33] <ndec> mpoirier: cooloney: ogra: so what do we need exactly on top of the current image to get audio out of the box? are you using SDP4430.conf file or not?
[21:34] <mpoirier> SDP4430.conf is not ready yet.
[21:34] <mpoirier> berco is working on it.
[21:34] <sguiriec> ndec: thanks nico for the info
[21:34] <ndec> mpoirier: i saw ogra comments on the bug, with the omap4 config file. what is this file? where is it supposed to come from, e.g. which package?
[21:35] <cooloney> ndec, firstly, we need merge those audio patches
[21:35] <mpoirier> ndec: I saw the comment to but havent' had time to try.
[21:35] <ndec> cooloney: agreed, on this. stability and sound quality is much better with those patches.
[21:36] <ndec> mpoirier: ok.. i thought you guys were talking about this in fact.
[21:36] <mpoirier> ndec: no, I'm doing test for sguiriec - he's helping us.
[21:36] <ndec> so we need ogra to explain why/how he did this change.
[21:36] <ndec> mpoirier: ok. which tests?
[21:36] <cooloney> ndec, for the SDP4430.conf or alsamixer configs, ogra will update that
[21:37] <ogra> ndec, that file apparently only works if you call alsactl init and requires a one line change to libasound0
[21:37] <ogra> (the omap4 file)
[21:38] <mpoirier> ndec: sguiriec needed information, I'm providing it.
[21:38] <mpoirier> sguiriec: plughw:0,0 also works.
[21:38] <sguiriec> ndec: With berco we have some trouble with latest Asla/Pulse release compare to his previous FS.
[21:39] <sguiriec> mpoirier: Good to see that port is working after good setting.
[21:40] <mpoirier> sguiriec: educate me here a little...
[21:40] <mpoirier> when doing aplay -l,
[21:41] <sguiriec> sguiriec: Just here for help
[21:41] <mpoirier> device 9, 11, 13, and 14 are associated with twl6040 codec.
[21:42] <mpoirier> how did you do the mapping with plughw:0,0 , plughw:0,3 and plughw:0,4 ?
[21:43] <mpoirier> sguiriec: 'cause those devices are not associtated with twl6040...
[21:44] <sguiriec> mpoirirer: These devices are here for BE ports or to bypass ABE. Diirect access to McPDM.
[21:45] <sguiriec> mpoirier: Here I think we need to update the wiki. plughw:0,0 is Multimedia port (FE port). This port can be sent on different BE ports (Headset/Handsfree)
[21:46] <mpoirier> sguiriec: here's another way of asking the same question: is the output of aplay -l related to plughw:0,x ?
[21:46] <sguiriec> mpoirier: mixer controls setting will enable the different paths.
[21:48] <sguiriec> mpoirier: Normaly when we are using ABE we should use plughw;0.x with x up to 8.
[21:49] <mpoirier> sguiriec: the ABE are accessed directly with the plughw:0,x ?
[21:49] <sguiriec> mpoirier: After we should used amixer controls in order to set the path between FE to BE ports.
[21:50] <mpoirier> sguiriec: let me summarise what I just learned...
[21:50] <sguiriec> mpoirirer: ALSA is accessed to ABE directly with a sDMA channel to ABE.
[21:51] <mpoirier> ABEs are access directly via plughw:0,x . But for this to work the path between FE and BE must be set.  Correct ?
[21:52] <sguiriec> mporirier: Yes otherwise ALSA will return an error
[21:53] <mpoirier> sguiriec: here's another question then:
[21:54] <mpoirier> sguiriec: is the path between ABEs and BEs always the same ?
[21:54] <sguiriec> mpoirier: No it can be changed accoridng to the use case.
[21:55] <mpoirier> sguiriec: the following has become my bedside reading: http://omappedia.org/images/c/c9/OMAP4_Audio_Phoenix.jpg
[21:56] <mpoirier> sguiriec: in this case, plughw:0,0 is related to which PDM ? (UL0...DL4)
[21:57] <mpoirier> sguiriec: if that question makes sense at all...
[21:57] <sguiriec> mpoirier: Here you are missing the ABE part. McPDM port is a kind of TDM port manages by ABE.
[21:57] <sguiriec> mpoirier: Until you do not have ABE picture your questions are normal.
[21:58] <mpoirier> sguiriec: the only time I saw a ABE was in the omap4 technical reference manual.
[21:59] <mpoirier> sguiriec: unless you have a better picture...
[21:59] <sguiriec> mpoirier: ABE graph is making the link beetween FE port and BE port. Typicaly McPDM is a BE port. McBSP is also a other BE port used for BT or MODEM call.
[22:01] <mpoirier> sguiriec: ya, I read about the McBSP but aren't much of interest in this case - correct ?
[22:01] <sguiriec> mpoirier: will check if I can provide you better picture tomorrow. Normally should be ok
[22:02] <sguiriec> mpoirier: For standard audio with Phoenix Audio McBSP is no interest for our use case
[22:02] <mpoirier> sguiriec: ok that is the conclusion I came up with.
[22:03] <mpoirier> sguiriec: i've known from the start i was missing information - anything you can get will  help.
[22:04] <sguiriec> mpoirier:of course. Will sync with ndec in order to help you on the topic. Quite new compare to OMAP3.
[22:06] <mpoirier> sguiriec: thanks.  your time and insight are well appreciated.
[22:09] <sguiriec> mpoirier: I hope we will reach to good SDP4430.conf file with berco. Will try to provide ABE/Phoenix audio picture for audio system understanting
[22:10] <mpoirier> ok
[22:10]  * ogra_ac still doesnt get why device 0,0 cant just properly connect to the working default codec in the driver 
[22:10] <ogra_ac> that would solve all our issues
[22:11] <mpoirier> ogra_ac: even if it would, the FE - BE path would not be established.
[22:14] <rsalveti> vincent-laptop: robclark: http://paste.ubuntu.com/506797/ an oops while restarting X11
[22:15] <sguiriec> orga_ac: SDP4430.conf should solve our problem by setting up the graph between FE and BE ports after the boot.
[22:17] <rsalveti> GrueMaster: http://people.canonical.com/~rsalveti/maverick/boot/es21/MLO-sdp
[22:17] <ogra_ac> sguiriec, yeah
[22:17]  * ogra_ac just commented on the bug
[22:23] <sguiriec> ogra_ac: Do you have any glue on potential recent update on ALSA or pulse that can explain different behavior in the reading of .conf audio file?
[22:23] <ogra_ac> no, sorry, i dont, do you know between which versions it changed ?
[22:24] <sguiriec> orga_ac: Can check tomorrow with berco? Do not have it from home.
[22:24]  * ogra_ac goes to check changelogs on launchpad
[22:25] <ogra_ac> sguiriec, but you are use it was a version in maverick ?
[22:25] <ogra_ac> s/use/sure/
[22:27] <sguiriec> orga_ac:thanks, I will check the chanelogs. berco has two FS. One is working and the one is not. There are based on maverick but version are not exactly the same. changelogs should help us
[22:29] <ogra_ac> yep, i'm just looking
[22:29] <ogra_ac> one prob is though that there camein a completely new upstream version at some point
[22:31] <rsalveti> robclark: http://gitorious.org/~rsalveti/pandaboard/rsalveti-x-loader/commits/omap4_panda_es2.1
[23:45] <rsalveti> vincent-laptop: robclark http://people.canonical.com/~rsalveti/maverick/boot/es21/MLO-lowvoltage
[23:45] <rsalveti> with                 *(volatile int*)(0x4A307BA0) = 0x3A5512;
[23:57] <devilhorns> grrr, really wish xvidcap would work so I could show you guys the unity-efl stuff