| === lilstevie|ZNC is now known as lilstevie | ||
| devilhorns | ogra, around/awake yet ? :) | 06:17 |
|---|---|---|
| persia | He's typically a couple more hours. | 06:18 |
| devilhorns | persia, ahh ok, thanks :) | 06:18 |
| persia | Find yourself at a loss during the pause-between-cycles? | 06:20 |
| devilhorns | persia, not at all :) plenty todo wrt unity-efl | 06:21 |
| devilhorns | persia, but, I do need to discuss something with him | 06:21 |
| persia | Ah, I can't help with that then. | 06:21 |
| devilhorns | hehe yea | 06:21 |
| devilhorns | ogra, when you get online, please drop me a PM. Need to discuss a few things with ya, thanks :) | 06:45 |
| lag | sebjan: Do you know who Misael Lopez Cruz is? | 07:49 |
| sebjan | lag: he is a TIer working on audio (don't know if he still works on audio, but at least he used to) | 08:07 |
| lag | sebjan: Does he still work for TI? | 08:07 |
| lag | sebjan: I'm wondering if it's worth asking him to the session | 08:08 |
| sebjan | lag: I don't know... best to ask Liam or Margarita | 08:11 |
| lag | Sure, thanks | 08:11 |
| === hrw|gone is now known as hrw | ||
| hrw | ehlo # | 08:33 |
| === lilstevie is now known as lilstevie|ZNC | ||
| ndec | ogra: hi... fyi: just sent you an email... | 09:08 |
| lool | vstehle: http://gitorious.org/croco | 09:47 |
| suihkulokki | vstehle what do you want to know about it? | 10:11 |
| === XorA|gone is now known as XorA | ||
| kornel` | hi | 10:46 |
| kornel` | does anyone has some experience of encoding video to h264 on arm processor. with ffmpeg or any other solution (which may use dps as well if necessary, etc) ? | 10:47 |
| persia | kornel`, What question would you ask if someone replied "Yes" to that? | 10:48 |
| kornel` | is it possible to encode a live stream with an arm (with neon) processor realtime? and if so, what quality? | 10:49 |
| hrw | depends on cpu, method used | 10:50 |
| kornel` | i would use arm cortex a8 | 10:50 |
| kornel` | how much does dsp matters? | 10:51 |
| persia | I'm not sure our encoders are NEON-enabled | 10:51 |
| hrw | kornel`: there is no such cpu as "arm cortex a8" | 10:51 |
| persia | kornel`, DSP only matters if there are kernel drivers or encoder-specific drivers for that DSP. | 10:51 |
| ogra | ndec, and i answered it :) | 11:01 |
| kornel` | ok thanks for answers | 11:02 |
| persia | kornel`, Just as summary, it's known possible for some chips, at some resolutions. It's unlikely we have a wide-enough body of experience to tell you whether any specific combination works. | 11:02 |
| kornel` | persia: right i will buy some and triing :) thanks! | 11:03 |
| persia | kornel`, Good luck. My recommendation is to get one from a vendor that has open encoders that are known to meet your application requirements. The SoC vendors usually are happy to explain just how cool each chip is. | 11:04 |
| armin76 | persia: yeah, like nvidia saying they don't need neon because their soc is awesome :P | 11:38 |
| persia | armin76, might be though: doesn't it support CUDA or something? | 11:39 |
| armin76 | cuda on arm? weird | 11:39 |
| vstehle | lool: Thanks! suihkulokki: I want to try croco on top of qemu/pbuilder, to speedup armel builds on PC. I would like to use the cross-compiler on the PC transparently instead of the qemu/armel gcc. This is to build Ubuntu packages. I have had no luck so far with xdeb. Google did not return much about croco, that's why I asked. | 11:40 |
| hrw | vstehle: distcc will do work | 11:44 |
| vstehle | hrw: I thought about that; less setup on PC, but more intrusive on package (need to override the compiler command, I guess). | 11:45 |
| hrw | or add one dir to PATH | 11:48 |
| persia | armin76, Why? the code runs on the GPU anyway: CPU architecture ought be irrelevant. | 11:49 |
| * hrw -> food | 11:57 | |
| persia | amitk, I had a chance to play with your kernel sources this weekend, but unpacking the 2.6.28 /proc/config.gz and `make oldconfig` still asked me *lots* of questions, including some about which boards to support. Do you have any recommendations for the config for a Netwalker? | 12:00 |
| lool | vstehle: You can use the hardening-wrapper trick to workaround this limitation | 12:00 |
| amitk | persia: start with mx51_defconfig and add compile-in support for the efikamx | 12:01 |
| persia | amitk, So I don't care about any of the options that were set on the Netwalker for the old kernel/ | 12:01 |
| persia | s:/:?: | 12:01 |
| amitk | persia: since all the HW doesn't yet work, no we don't care about the netwalker options ATM. | 12:02 |
| persia | Heh, fair. I'll try it with the mx51_defconfig, and see what works or doesn't. if I have screen, keyboard, WiFi, MTD, and SD, I'm sufficiently happy. | 12:03 |
| amitk | persia: you'll get serial and ethernet now. The linaro kernel might get the mmc/sd patches too. Wifi is WIP. | 12:07 |
| persia | Oh. Since my hardware has no serial or ethernet, that's not very useful. | 12:08 |
| armin76 | persia: what wifi does it have? | 12:10 |
| persia | armin76, I'm not sure precisely: something that uses "ks7010_sdio" | 12:14 |
| armin76 | yuck | 12:16 |
| persia | Why? | 12:16 |
| armin76 | just curious | 12:16 |
| persia | No, why "yuck"? | 12:16 |
| armin76 | ah, its a renesas chipset | 12:16 |
| persia | And this is bad because ... ? | 12:17 |
| armin76 | oh, because it didn't ring a bell at all | 12:17 |
| * persia doesn't usually see "yuck" used to mean "never heard of it" and wanders off, no longer concerned | 12:17 | |
| armin76 | didn't know that renesas did wifi chips :) | 12:17 |
| hrw | persia: ks7010_sdio is kernel module? | 12:18 |
| persia | hrw, No, kernel module is ks79xx_sdio | 12:18 |
| persia | amitk, Actually, before I give up, are there any tests that I could perform using your kernel that you'd find useful, given no ethernet and no serial? | 12:19 |
| amitk | persia: probably not, just wait some more to get the rest of the patches in place.. | 12:20 |
| persia | amitk, OK. Please let me know if I can help with testing, as I'll be able to make time for it fairly freely between now and the beginning of April. | 12:21 |
| armin76 | ogra: does the ac100 have a temperature sensor? | 12:53 |
| === hrw is now known as hrw|afk | ||
| === zyga is now known as zyga-break | ||
| === ogra_ is now known as ogra | ||
| === zyga-break is now known as zyga | ||
| lool | Hmm | 14:55 |
| lool | I've been looking whether extras.ubuntu.com is disabled on ARM or not | 14:56 |
| lool | it seems not | 14:56 |
| lool | does someone confirm that extras.ubuntu.com shows up in sources.list after an Ubuntu install on ARM? | 14:56 |
| GrueMaster | It isn't in the preinstalled images sources.list, just the live images. | 14:56 |
| GrueMaster | And yes, I see it on dove. | 14:57 |
| lool | GrueMaster: Does it work when you apt-get update? | 14:58 |
| lool | GrueMaster: I'd expect some APT errors | 14:58 |
| GrueMaster | Yes, I get errors. | 14:59 |
| lool | GrueMaster: ah, is this reported somewhere already? | 14:59 |
| GrueMaster | Apparently, it isn't limited to armel. It was discussed a few days ago on #u-release. | 14:59 |
| lool | I checked this morning, and saw that the keyring was built on armel, seeded on armel, and that the apt-setup/extras setting was off unless preseeded to true, which is the case in all desktop images | 14:59 |
| lool | GrueMaster: Ok thanks | 14:59 |
| lag | o/ | 15:00 |
| ogra | lag, isnt it in 1h ? | 15:00 |
| lag | UTC != GMT | 15:01 |
| ogra | (unless date -u lies to me) | 15:01 |
| ogra | oh, you sheduled it for GMT ? | 15:01 |
| * ogra thought he read UTC | 15:01 | |
| lag | Same thing | 15:01 |
| ogra | It will be hosted in #ubuntu-arm on freenode @ 15:00 UTC. | 15:01 |
| lag | I forget we're in GMT+1 | 15:01 |
| ogra | ogra@osiris:/var/build/images$ date -u | 15:02 |
| ogra | Di 12. Okt 14:01:59 UTC 2010 | 15:02 |
| ogra | right | 15:02 |
| lag | Bloodly British and their stupid saving hrs | 15:02 |
| ogra | heh | 15:03 |
| === zyga is now known as zyga-afk | ||
| === hrw|afk is now known as hrw | ||
| ogra | lag, do you have a build with the changes from liam ? | 15:52 |
| devilhorns | ogra, you get my email ? | 15:53 |
| lag | ogra: Nope | 15:53 |
| lag | Bit late to ask now | 15:53 |
| ogra | devilhorns, yes, need to talk with davidm | 15:58 |
| devilhorns | ogra, ok, no problem :) | 15:58 |
| lag | Let's try this again ... | 16:00 |
| lag | o/ | 16:00 |
| mpoirier | o/ | 16:01 |
| diwic | o/ | 16:01 |
| berco | o/ | 16:01 |
| sebjan | o/ | 16:01 |
| amitk | \o | 16:01 |
| lag | We have an intruder | 16:01 |
| lag | ;) | 16:01 |
| amitk | ;) | 16:01 |
| lag | lrg: ? | 16:01 |
| * ogra is here | 16:02 | |
| lrg | lag: here | 16:02 |
| lag | Then we shall begin | 16:02 |
| lag | Firstly we need to get everyone up to speed | 16:02 |
| lag | I'm guessing lrg knows the most about this | 16:03 |
| lag | Care to give us a rundown? | 16:03 |
| ogra | do we have rama here ? | 16:03 |
| lag | Not seen | 16:03 |
| rsrimushnam | Here | 16:03 |
| lag | rsrimushnam: Welcome | 16:04 |
| ogra | perfect :) | 16:04 |
| lag | ... | 16:04 |
| lag | ogra: Care to start us off? | 16:04 |
| ogra | well, we dont really know ehere the issues lie yet, it is clear that sound currently doesnt work at all on the panda (or other omap4 platforms) | 16:06 |
| lag | I thought we had sound via ALSA? | 16:06 |
| ogra | there are a) the backend routes not properly set by default | 16:06 |
| ogra | b) alsa seems to have issues | 16:06 |
| ogra | (i discussed with crimsun last night and he pointed me to a bug i noted into our bug) | 16:07 |
| ogra | b might be solved by the SRU crimsun plans | 16:07 |
| ogra | lag, we do but thats just through a slightly better hack | 16:07 |
| lag | I know there as been a tussle with userspace and kernel with regard to who's problem it is - has this been answered yet? | 16:07 |
| lrg | ogra: care to expand on (b) | 16:08 |
| ogra | though as i understand it, my hack will turn into the default in future alsa (using the init subdir) | 16:08 |
| lag | (b) is a libalsa issue is it not | 16:08 |
| lag | Do you have the bug number to hand? | 16:08 |
| ogra | lrg, i cant expand much more than whats written on the bug, he just told me it would very likely improve things | 16:08 |
| ogra | bug 652035 | 16:08 |
| ubot2 | Launchpad bug 652035 in alsa-lib (Ubuntu) "libasound2 not finding usb sound card (affects: 1) (heat: 6)" [Medium,In progress] https://launchpad.net/bugs/652035 | 16:08 |
| ogra | seems some of the parsing isnt done right | 16:09 |
| ogra | there is an upstream fix and an additional fix crimsun added | 16:09 |
| ogra | i wish he could be here now, since he does most of the ubuntu alsa maintenance | 16:09 |
| lag | It sounds like there are more issues than meets the eye | 16:09 |
| ogra | but it sadly collides with his work hours | 16:09 |
| lag | Why do these work on other systems and not OMAP4? | 16:10 |
| ogra | lag, well, the bug only explains why i have to call alsactl init manually | 16:10 |
| ogra | which is anyway not the target we want to achieve | 16:10 |
| berco | Is alsa-utils script call at all? It seems this script resets alsa values and has some cases based on platforms | 16:10 |
| ogra | berco, yes, it is called properly | 16:11 |
| ogra | and as i said above, the future of alsa seems to be to use these init scripts | 16:11 |
| berco | but I don't know if it is called before SDP4430.conf is read... | 16:11 |
| berco | it could overwrite SDP4430, right? | 16:11 |
| ogra | berco, i didnt use SDP4430.conf at all | 16:12 |
| ogra | after boot i have the right mixer settings using my way | 16:12 |
| diwic | looking at crimsun's patch for 652035 (which I believe I saw upstream as well), it's about not quitting early when finding gaps/holes in the list of subdevices | 16:12 |
| ogra | but no sound until i call aslactl init | 16:12 |
| ogra | diwic, so that could be the reason why the extra alsactl init is needed then | 16:12 |
| ogra | i.e. my scrip should work fine with that fix | 16:13 |
| ogra | but thats only half the solution | 16:13 |
| berco | ok. so do we want to fix your way first ogra? or is the purpose of the brainstorm to move away from this method and use SDP4430.conf file? | 16:13 |
| persia | ogra, Which init script is your script? | 16:13 |
| ogra | persia, the one attached to our bug | 16:13 |
| ogra | https://bugs.edge.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/637947/comments/24 | 16:13 |
| ogra | and | 16:13 |
| ubot2 | Launchpad bug 637947 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "no sound devices on current ES2.0 boards (affects: 2) (dups: 1) (heat: 26)" [High,Confirmed] | 16:13 |
| ogra | https://bugs.edge.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/637947/comments/25 | 16:14 |
| ogra | berco, well, my script has two probs | 16:14 |
| ogra | a) these scripts want more info which the driver doesnt expose atm so we cant really differ between different omap4 boards | 16:14 |
| ogra | which is indeed bad unless the blaze uses exactly the same setup | 16:15 |
| persia | Ah, OK. I thought it was something different :) | 16:15 |
| ogra | and b) more seriously HDMI doesnt get initialized and exposed to pulse | 16:15 |
| ogra | imho b) is only solvable through SDP4430.conf | 16:15 |
| ogra | but that could be a massively simpler one if it goes hand in hand with my init script | 16:15 |
| ogra | since we dont need to set volumes from the .conf | 16:16 |
| ogra | for a) we would need to extend the driver to expose more than just the card name | 16:16 |
| ogra | if you look at /usr/share/alsa/init/hda you can see how you can set different mixers based on the board | 16:17 |
| ogra | but we would need a mixername | 16:18 |
| ogra | note that i also havent tried the fix from bug 652035 yet, all this is based on assumptions | 16:18 |
| lrg | ogra: I could also add the machine name etc SDP4430/Panda/Blaze into the card name for (a) | 16:18 |
| ubot2 | Launchpad bug 652035 in alsa-lib (Ubuntu) "libasound2 not finding usb sound card (affects: 1) (heat: 6)" [Medium,In progress] https://launchpad.net/bugs/652035 | 16:18 |
| persia | Is b) only soluable through SDP4430.conf? Can't we hint it by providing more inputs to pulse's module-udev-detect? | 16:18 |
| ogra | lrg, yeah, that would be good | 16:18 |
| abduenas | I have HDMI working from PA | 16:19 |
| ogra | persia, its about outputs :) | 16:19 |
| diwic | so for exposing HDMI to pulse, first - do we want one output at a time or is the hardware capable of multiple independent streams? | 16:19 |
| abduenas | it's justa a matter of creating a PA profile (which I'm working on at this moment) | 16:19 |
| persia | ogra, Right, so we expose more data in /sys/ that udev and pulse use to set the outputs. | 16:19 |
| persia | abduenas, We're looking at autodetection solutions only. | 16:19 |
| ogra | we want either a selectable output in the audio prefs (with a default to analog) or a mirrored output | 16:19 |
| ogra | i'd say | 16:19 |
| persia | I think the regular pulse output UI is fine. Let's not fuss with that. | 16:20 |
| ogra | abduenas, we cant touch pulse config | 16:20 |
| ogra | persia, yes, its fine and i saw hdmi exposed in it | 16:20 |
| diwic | persia, there are already mixer profiles for other cards in the default config | 16:20 |
| abduenas | PA profile has nothing to do with touching pulse default.pa config | 16:20 |
| ogra | thats what i mean by selectable output | 16:20 |
| rsrimushnam | ogra: we need to be able to support discrete streams on different outputs -- not just mirrored | 16:20 |
| * jayabharath wonders if davidm is back in town... need to send a platform to hrw... | 16:20 | |
| ogra | rsrimushnam, right, so selectable with default to analog it is | 16:21 |
| persia | rsrimushnam, We can do that, but we don't tend to expose the UI for that by default. Interested folks are usually directed to install pavucontrol | 16:21 |
| diwic | persia, upstream ships with files for e g native-instruments-audio8dj.conf and a few others | 16:21 |
| persia | diwic, Yep. | 16:21 |
| tw_ | Hate to bother you people but were would I go to get some help installing ubuntu on the BeagleBoard. I have tried http://testcases.qa.ubuntu.com/Install/ARM/PreinstalledImage but it won't boot. | 16:21 |
| persia | tw_, Are you able to wait ~45 minutes? | 16:22 |
| lag | tw_: #beagleboard | 16:22 |
| lag | tw_: #beagle | 16:22 |
| lag | Even | 16:22 |
| tw_ | Yes | 16:22 |
| tw_ | Why? | 16:22 |
| persia | tw_, If the folks in #beagle can't help, ask us again then, and we'll help. | 16:22 |
| ogra | thats bad | 16:22 |
| ogra | dont point him to #beagle | 16:23 |
| ogra | they dont use ubuntu usually | 16:23 |
| * persia will help tw elsewhere: please continue the sound meeting | 16:23 | |
| lag | tw_ I'll talk to you via other means - bear with me | 16:23 |
| tw_ | btw: I am using one of the new BB_xm boards. | 16:23 |
| diwic | anyway, it all comes down to, either we adjust the mixer names (in the driver) so pulseaudio can autodetect the profile, or we take abduenas PA profile when it's ready | 16:23 |
| ogra | where would that pa pfrofile go ? | 16:24 |
| diwic | /usr/share/pulseaudio/alsa-mixer/profile-sets | 16:24 |
| diwic | and an udev rule to go with it | 16:24 |
| persia | Let's do the former. There's a high likelihood that we'll see lots more boards use this SoC, and we need per-board stuff in the driver anyway. | 16:24 |
| ogra | hmm | 16:24 |
| lrg | diwic: PA autodetection is wrong, we must be more explicit | 16:24 |
| ogra | diwic, how do you make sure that doesnt collide with the already existing udev rule ? | 16:25 |
| persia | Did anyone ever get module-udev-detect working? Last I saw, folks were still hardcoding the modules for pulse. | 16:25 |
| diwic | lrg, can you elaborate? | 16:25 |
| ogra | persia, yes, my init script works without any extras | 16:25 |
| ogra | but with the above limitations | 16:25 |
| persia | With regular default.pa? | 16:25 |
| ogra | yes | 16:25 |
| persia | Oh, cool. | 16:26 |
| ogra | no changes to pulse at all | 16:26 |
| ogra | just the one line change to 00main and the script in place | 16:26 |
| lrg | diwic: auto detection depends on PA making guesses about the underlying audio hardware. | 16:26 |
| ogra | and the nasty extra alsactl init call | 16:26 |
| persia | Ah, so comment 13 wasn't wrong after all. | 16:26 |
| berco | ogra: it's one line in 00main + one omap4 file, right? | 16:26 |
| ogra | persia, yes, thats what made me develop that script | 16:27 |
| ogra | berco, xactly | 16:27 |
| ogra | no further changes | 16:27 |
| persia | berco and I had thought that was wrong after some experimentation, leading to the SDP4430.conf route | 16:27 |
| diwic | lrg, so then we must trace down where PA guesses wrong and evaluate what to do in each particular case | 16:27 |
| ogra | if you then call aslactl init at some point after boot sound works fine through analog | 16:27 |
| berco | wondering if we don't want to use udev as much as possible to avoid multiple conf files to maintain | 16:27 |
| ogra | udev does its job already | 16:28 |
| lrg | diwic: the answer is UCM when it's ready, this way PA does not need to do nasty probing on each PCM that it does now. | 16:28 |
| ogra | with the init scrip the mixers are all set properly right after boot (and without asound.state file in place) | 16:28 |
| persia | diwic, We'd do that in /usr/share/pulseaudio/alsa-mixer/paths/*, right? | 16:28 |
| persia | lrg, Do we expect UCM by February? | 16:29 |
| ogra | well, as i understood crimsun UCM is whgat these init scripts are | 16:29 |
| ogra | or at lest the start of UCM | 16:29 |
| lrg | persia: yes, we are pshing Jaroslav to move it to his master branch ins alsa-lib.git | 16:29 |
| diwic | persia, those provide input for the probing as well as being a poor man's UCM, yes | 16:29 |
| persia | Let's design a UCM-based solution then, and use that for Natty then. | 16:30 |
| === zyga-afk is now known as zyga | ||
| lrg | persia: please everyone feel free to mail Jaroslav on UCM progress on alsa-dev. this may speed up progress | 16:30 |
| ogra | persia, we need a solution this week | 16:30 |
| diwic | lrg, but UCM or not, having uniform control names is still a good thing | 16:30 |
| persia | And provide a pulse profile for maverick users. | 16:30 |
| ogra | persia, i dont care about natty | 16:30 |
| ogra | the SRU needs to be in before friday | 16:31 |
| persia | ogra, But you will, so I'll care for you today :) | 16:31 |
| ogra | natty is well ... natty | 16:31 |
| lrg | diwic: uniform control names can apply to some audio hardware but unfortunately not all :( | 16:31 |
| * persia owns some hardware that would have difficulty with uniform control names | 16:32 | |
| diwic | lrg, so if this particular hardware can't have standard control names, we write a pa profile to compensate? | 16:32 |
| diwic | lrg, assuming UCM is not available | 16:33 |
| lrg | diwic: yes, agreed | 16:33 |
| persia | So, pulseaudio-profile for maverick and UCM for natty? | 16:34 |
| ogra | hrm | 16:34 |
| persia | We'll still have 652035 though. | 16:34 |
| persia | Has anyone tried the proposed SRU on an omap4 board with the alsa init script? | 16:34 |
| ogra | not yet | 16:35 |
| ogra | will the pulse profile help to initialize the right backend routing ? | 16:35 |
| abduenas | nop | 16:35 |
| * ogra doesnt belive it scratches more than the surface | 16:35 | |
| ogra | right | 16:35 |
| persia | The pulse profile will tell pulse the control names to use. | 16:36 |
| ogra | so that doesnt help at all | 16:36 |
| persia | Are you saying the HDMI out isn't even initialised with the init script? | 16:36 |
| ogra | oh, you mean only for adding HDMI ? | 16:36 |
| ogra | i understood as a general solution for the problem | 16:36 |
| diwic | I think there is some confusion about the "backend routing", what is that really about? | 16:37 |
| persia | Right. Complete maverick solution is 652035 fix + alsa init script + pulse profile | 16:37 |
| ogra | diwic, adding the right codec to the control | 16:37 |
| persia | Natty solution would be UCM-based and may or may not need a pulse profile depending on whether we can categorise the hardware sensibly in shipping products. | 16:37 |
| ogra | persia, ah, now i understand | 16:37 |
| hrw | kgilmer: hi here | 16:39 |
| ogra | diwic, currently alsa device 0,0 points to a null sink | 16:39 |
| ogra | by default | 16:39 |
| === miguel is now known as Guest56473 | ||
| diwic | ogra, can all subdevices be used in parallel? | 16:39 |
| ogra | i dont know | 16:40 |
| diwic | or does the hw just support one stream at a time? | 16:40 |
| ogra | i'm really no audio guy, only worked into that during last week :) | 16:40 |
| ogra | i think it shoudl support more | 16:40 |
| diwic | lrg, ^ | 16:40 |
| persia | HW supports multiple streams | 16:40 |
| Guest56473 | Hi i just recentñy buy a DevKit8000 and i want to run Ubuntu on it, i have already read the wiki. But when i boot from the SD the boot hang out | 16:40 |
| persia | rsrimushnam, Can you confirm that? | 16:40 |
| ogra | but one of lrg or rsrimushnam should be able to answer | 16:40 |
| rsrimushnam | It can support more than one stream. But not necessarily all simultaneously. | 16:40 |
| persia | rsrimushnam, Do we need to worry about how many it can support at once? | 16:41 |
| Guest56473 | at kjourlald | 16:41 |
| lrg | ogra: UCM will export this multiple stream info to PA too | 16:41 |
| abduenas | PA profile can also tell PA about the other hw devices | 16:41 |
| rsrimushnam | worry from what respect? | 16:42 |
| diwic | abduenas, that was my thought as well | 16:42 |
| persia | rsrimushnam, Limit the number of simultaneous streams in the UI or something. | 16:42 |
| kgilmer_ | hi hrw :) | 16:43 |
| rsrimushnam | I guess the way we had visualized this, PA would route audio to the different available sinks on the driver and handle mixing streams to a single sink there. So from the UI POV, this should be transparent, I would think, | 16:43 |
| kgilmer_ | hrw, i'm curious how rootstock differs from oe? does rootstock run entire build on arm via qemu? | 16:43 |
| persia | rsrimushnam, That's easlier then. Thanks. | 16:44 |
| hrw | kgilmer_: it just uses packages from feeds + some mangling | 16:44 |
| diwic | so does the driver "probe" the codec and construct devices appropriately? Or are the subdevices hard-coded in the driver? | 16:44 |
| persia | The subdevices appear to be constructed by the alsa init script | 16:45 |
| berco | Going back to "Complete maverick solution is 652035 fix + alsa init script + pulse profile". rsrimushnam: are you going to provide us the PA profile? | 16:45 |
| rsrimushnam | Yes. | 16:46 |
| berco | so are we sure "652035 fix + alsa init script + pulse profile" will be enough? no need for a sdp4430.conf file or else? | 16:46 |
| rsrimushnam | abduenas is working on it now. | 16:46 |
| abduenas | actually the PA guys are willing to include that on PA package, as native-instruments-audio8dj.conf | 16:46 |
| diwic | persia, the init script as posted in comment #25 does not add any subdevices? | 16:46 |
| kgilmer_ | hrw, packages = binary packages? | 16:47 |
| persia | berco, I think ogra said that he didn't need SDP4430.conf with the init script. | 16:47 |
| diwic | persia, could you point me to that init script? | 16:47 |
| berco | abduenas: ok, I see. That's fair | 16:47 |
| persia | diwic, Then I'm mistaken. | 16:48 |
| ogra | persia, right | 16:48 |
| hrw | kgilmer_: yes | 16:48 |
| mpoirier | diwic, the scripts simply connect backends to frontends. | 16:48 |
| ogra | diwic, its attached to the bug | 16:48 |
| berco | persia: I agree. Just wanted to make sure we discard this approach of SDP4430.conf | 16:48 |
| kgilmer_ | where do the binary packages get generated hrw? | 16:48 |
| diwic | ogra, so it is the #25 comment attachment? | 16:48 |
| ogra | diwic, right together with the change to 00main | 16:48 |
| ogra | (from 24) | 16:48 |
| hrw | kgilmer_: ah that your gentoo roots... | 16:49 |
| diwic | so then I'll reask my question: does the driver "probe" the codec and construct devices appropriately? Or are the subdevices hard-coded in the driver? | 16:49 |
| ogra | they are apparently not since oyu need that script | 16:49 |
| mpoirier | nothing is hardcoded in the driver. | 16:49 |
| hrw | kgilmer_: in debian (and derived) binary packages are built by builddeamons | 16:49 |
| mpoirier | they FE and bE are initialised and left for userspace to connect. | 16:49 |
| diwic | mpoirier, who decides that 0,0 is a null sink and 0,7 (?) is HDMI? | 16:50 |
| diwic | e g | 16:50 |
| kgilmer_ | hrw, ah ic. those biuld daemons are running on target architecture or they are cross compiling? | 16:50 |
| berco | ogra: so for the init script, will it be a udev rule? | 16:50 |
| hrw | kgilmer_: target - only native builds are done | 16:50 |
| ogra | berco, there is a udev rule already | 16:50 |
| mpoirier | diwic:the null sink is simply the first on the list. I beleive moving it down would put another sync as the default | 16:51 |
| kgilmer_ | interesting hrw | 16:51 |
| lrg | diwic: the pcm mappings are done in the machine driver | 16:51 |
| lrg | have a look at sdp4430.c | 16:51 |
| ogra | berco, you only need to dump the script into /usr/share/alsa/init/ | 16:51 |
| berco | ogra: oops, sorry. Thought alsactl init was still missing | 16:51 |
| * kgilmer_ sees a chicken and egg problem. | 16:51 | |
| ogra | berco, right | 16:51 |
| hrw | kgilmer_: you mean "bootstrap" problem? | 16:51 |
| ogra | berco, but thats only to actually init, the mixers are all set right already and properly routed | 16:52 |
| kgilmer_ | yeah hrw | 16:52 |
| ogra | berco, the hope is that the aösa-lib fix solves the needed init | 16:52 |
| berco | ogra: missed that one :). Now I understand the #652035 need :) | 16:52 |
| ogra | :) | 16:53 |
| berco | so just waiting for rsrimushnam profile and we can test :) | 16:53 |
| berco | rsrimushnam: when do you think you can provide us a profile-set to test? | 16:54 |
| berco | sorry, most likely to be abduenas | 16:54 |
| rsrimushnam | we have something started already but we are still having issues with it. abduenas can elaborate | 16:54 |
| berco | who provides this file | 16:54 |
| hrw | kgilmer_: both distros did bootstrap long time ago | 16:54 |
| rsrimushnam | fyi: I need to drop off in 5 minutes... | 16:55 |
| berco | rsrimushnam: abduenas: I think we just need to get a rough idea of the timeframe | 16:55 |
| abduenas | i'm just missing the udev rule in /lib/udev/rules.d/90-pulseaudio.rules to be able to read omap3.conf | 16:55 |
| abduenas | but i'm udev nubee | 16:55 |
| ogra | abduenas, ugh, a udev rule for pulse ? | 16:56 |
| diwic | So the problem is then: that PA should switch subdevice on the fly (i e when user switches from "Headset" to "HDMI") in a way it currently can't do? | 16:56 |
| abduenas | sorry meant to say omap4.conf (or wahtever) | 16:56 |
| berco | abduenas: don't hesitate to come to this channel and ask for help. If we can we will help | 16:56 |
| persia | diwic, Why does it need to be different than what we do for headset/HDMI for anything else? | 16:56 |
| lrg | lag: are you taking a note of any actions here btw ? | 16:56 |
| lag | I wasn't no | 16:57 |
| persia | (irclogs.ubuntu.com can help if it's not being done in realtime) | 16:57 |
| ogra | abduenas, are you sure that is used at all when pulse runs on a per user base ? | 16:57 |
| berco | ogra: this udev rule already exists. | 16:57 |
| lrg | persia: I'm forgetful ;) | 16:57 |
| ogra | (which is the default in ubuntu) | 16:57 |
| lag | I don't think we have a meeting bot in here | 16:57 |
| diwic | persia, current PA structure is either switch between different cards, or switch "connector" (which it does by setting volume controls, not by switching subdevice) | 16:57 |
| ogra | berco, right, but i think only if pulse runs as a system daemon it is used | 16:57 |
| berco | ogra: I see. | 16:58 |
| persia | lag, We don't. I don't want to have enough meetings here to add one, but I'm willing to be convinced. | 16:58 |
| ogra | berco, i'm not sure though | 16:58 |
| ogra | berco, abduenas, that should be heavily tested | 16:58 |
| persia | diwic, Aha. OK. I guess I've not actually used PA with my harder-to-define cards. | 16:58 |
| abduenas | i'm able to use it on per-user basis | 16:58 |
| lag | persia: No, it's okay :) | 16:58 |
| ogra | abduenas, thanks that helps :) | 16:59 |
| lag | I we'll have to have a wash-up when the meeting has finished | 16:59 |
| lag | Who's doing what etc | 16:59 |
| ogra | so who is fixing the driver side ? | 16:59 |
| persia | lag, It's also worth separating into two discussions moving forward: maverick hacks and natty solution. | 16:59 |
| lrg | ogra: what part of the driver ? | 17:00 |
| ogra | to expose the board name | 17:00 |
| lrg | the name ? | 17:00 |
| lrg | ah, ok - me :) | 17:00 |
| ogra | :) | 17:00 |
| berco | cool :) | 17:00 |
| ogra | like in the hda init file | 17:00 |
| ogra | i'm happy to add my init file to alsa-libs in an SRU | 17:00 |
| ogra | and the one line change to 00main | 17:00 |
| diwic | persia, the question is if that can be worked around in the pa profile, and it might be if the subdevices are stable | 17:00 |
| abduenas | i'm working on the PA profile for SDP4430/OMAP4 | 17:00 |
| ogra | abduenas, will you test on all available omap4 hw ? | 17:01 |
| ogra | (panda, blaze tablet) | 17:01 |
| === Neko__ is now known as Neko | ||
| persia | diwic, For the small number of devices to be fixed for maverick, I think we can find a way to fake that. We'll need a richer interface for natty. | 17:01 |
| abduenas | i have a blaze but no panda... although i can borrow one ... i think | 17:01 |
| Neko | hey guys what's the procedure for cross compiling a package | 17:01 |
| persia | Neko, We try to avoid it at all costs. | 17:02 |
| ogra | (though i guess we can be a bit ignorant about tablet since it uses a different kernel anyway) | 17:02 |
| armin76 | haha | 17:02 |
| persia | Neko, That said, there's a cross-toolchain package in the archives | 17:02 |
| Neko | yes but consider I have a nice fast box here to cross compile xserver or so.... | 17:02 |
| Neko | I have the toolchain | 17:02 |
| berco | abduenas: if you have something to be ready for test, let me know. I can run the test on my panda to help | 17:02 |
| Neko | but if I dpkg-build it's gonna use native right? | 17:02 |
| persia | Right. | 17:02 |
| abduenas | berco: roger that | 17:02 |
| ogra | lag, so was that enough as a summary for your notes ? | 17:02 |
| persia | And lots of packages are packaged in a way that means they can't be cross-compiled. | 17:02 |
| berco | abduenas: also good to be able to reproduce | 17:02 |
| ogra | (who -> what) | 17:02 |
| Neko | I guess the answer is, then, don't bother.. | 17:03 |
| persia | That's what we devided, yeah. | 17:03 |
| ogra | Neko, so i found the issue to your gdm vs oem-config bug | 17:03 |
| hrw | Neko: "xdeb -a armel --apt-source packagename" | 17:04 |
| lag | ogra: Sure | 17:04 |
| ogra | great :) | 17:04 |
| persia | Neko, hrw is the local cross-compilation expert if you really want to dig: just be warned it's not as trivial as just expecting dpkg-cross to actually work. | 17:04 |
| lag | Unless there's anything else anyone wants to add? | 17:04 |
| * ogra is fine as long as sound works on friday :) | 17:04 | |
| hrw | Neko: it may fail (probably will). next step is adding "--only-explicit" to xdeb call. this also may fail | 17:04 |
| Neko | ogra, amazing what is the problem? | 17:04 |
| Neko | I didn't get a bug update | 17:04 |
| Neko | hrw, thx maybe I will look into it.. for now though, native, since this seems like it may fail | 17:05 |
| ogra | Neko, because the bug is invalid ... its the way rootstock rolls the tarball | 17:05 |
| hrw | Neko: last step is "dpkg-buildpackage -b -aarmel" as xdeb steps should give you build deps | 17:05 |
| diwic | abduenas, you're also welcome to contact me if you need someone to discuss PA profiles with | 17:05 |
| Neko | ogra, argh? | 17:05 |
| abduenas | diwic: thnx! | 17:05 |
| * berco thinks it "sounds" better than an hour ago :) | 17:05 | |
| hrw | Neko: debian and derived are not cross compilation ready | 17:05 |
| Neko | so maybe update the bug as invalid with a comment that rootstock rolls the tarball badly? :) | 17:05 |
| Neko | hrw, I know, nothing is.. :( | 17:05 |
| ogra | Neko, if you just use tar, uid's and gid's will be taken from /etc/passwd and group of the host system | 17:05 |
| persia | Neko, Just build faster boxes :) | 17:06 |
| ogra | Neko, rootstock needs to use --numeric-owner to make sure owners of the files dont change | 17:06 |
| Neko | hmm has this been patched already? | 17:06 |
| ogra | Neko, thast something you will only hit of you build newer releases on older boxes | 17:06 |
| ogra | not yet, i need to discuss with rsalveti once he is back | 17:06 |
| Neko | yeah I was building maverick on lucid... | 17:06 |
| Neko | but also building lucid on lucid broke like that | 17:07 |
| ogra | (public holiday at his place today) | 17:07 |
| lag | In case there is any doubt | 17:07 |
| lag | [END MEETING] | 17:07 |
| lag | Thank you everyone | 17:07 |
| lag | I'll be in touch | 17:07 |
| diwic | thanks, bye | 17:07 |
| Neko | basically because on x86 and armel the user ids not necessarily the same... | 17:07 |
| ogra | Neko, well, as long as there is a diff between host and VM | 17:07 |
| ogra | right | 17:07 |
| ogra | not even between two x86 boxes thats guaranteed | 17:07 |
| hrw | Neko: OpenEmbedded allows to cross compile big amount of stuff in automated way | 17:07 |
| ogra | the system users are created by the packages | 17:07 |
| mpoirier | sguiriec: were you able to bet me docs for the complete audio path we talked about ? | 17:08 |
| ogra | so it only depends on the order | 17:08 |
| === diwic is now known as diwic_afk | ||
| ogra | (in which the packages are installed) | 17:08 |
| Neko | hrw yes and opensuse build service manages too.. the big trick is use qemu | 17:08 |
| Neko | but installing a full system then qemu then build is overkill | 17:08 |
| ogra | opensuse does some very nasty things though | 17:09 |
| Neko | yep I know | 17:09 |
| ogra | injecting x86 libs and binaries | 17:09 |
| sguiriec | mpoirier:I have prepare a picture. Need to make minor correction | 17:09 |
| Neko | I got my "I contribute" t-shirt for reporting tons of bugs :] | 17:09 |
| mpoirier | sguiriec: cool. | 17:09 |
| Neko | okay.. so... | 17:09 |
| Neko | ogra, if I hack my rootstock to have this --numeric-owner stuff it will magically start to work better? | 17:09 |
| persia | sbuild can run over qemu as well: the results were not as exciting as initially thought... | 17:09 |
| sguiriec | mpoirier: sorry a little bit busy on other stuff. Will try to push it today | 17:10 |
| hrw | Neko: OE does cross only - qemu is used only for generation of glibc l10n packages (and can be disabled) | 17:10 |
| hrw | Neko: but thats #ubuntu not #oe | 17:10 |
| mpoirier | sguiriec: that's ok, I've been elsewhere too. | 17:10 |
| ogra | Neko, it should, i haent tested it yet but hit the exact same issue as you with a tarred up rootfs that i repacked on different boxes | 17:10 |
| ogra | Neko, so finding all tar calls in rootstock and adding --numeric-owner should solve it | 17:10 |
| Neko | hrw, I have some experience with OE, but I quit using it about 18 months ago | 17:11 |
| persia | Neko, Did you never have success with livecd-rootfs and debian-cd? | 17:11 |
| sguiriec | mporier: I will give you the link as soon as I have done the update. | 17:12 |
| Neko | persia, I never got to try it | 17:12 |
| Neko | I am stuck doing kernel stuff | 17:12 |
| Neko | but since mav got released.... | 17:13 |
| Neko | I am building rootstocks | 17:13 |
| * ogra would also recommend livecd-rootfs over rootstock if you want to release images | 17:13 | |
| Neko | I need a rootstock first before I can do that though | 17:13 |
| ogra | rootstock is great for home use | 17:13 |
| Neko | chicken-egg really | 17:13 |
| persia | Ah, OK. I'll hope you have a chance to switch before natty, as rootstock isn't tested well, and mostly meant for hacking about rather than working systems. | 17:13 |
| ogra | but nothing for doing official releases | 17:13 |
| Neko | these rootstocks right now are for *me* only | 17:13 |
| Neko | we have released on a board already but.. it was a hateful solution | 17:14 |
| persia | For now, stick with what you have. When you have a few hours, come back, and we'll help you switch. | 17:14 |
| hrw | have a nice rest of day | 17:14 |
| Neko | maybe in 6 weeks? :D | 17:14 |
| === hrw is now known as hrw|gone | ||
| ogra | Neko, will you be at UDS ? | 17:15 |
| persia | Neko, 6 weeks sounds about perfect, sure. | 17:15 |
| Neko | no but Konstantinos will be | 17:15 |
| Neko | (markos, armhf debian) | 17:15 |
| ogra | we could sit down one evening and fix :) | 17:15 |
| Neko | unfortunately UDS happens during the school year so it's impossible for me to take time out to do it | 17:15 |
| berco | ogra: do we also need to add the user to audio&pulse groups? | 17:54 |
| Neko | yay, ogra, made a little fix for rootstock, worked :D | 18:00 |
| Neko | so that numeric-owner thing is exactly it | 18:00 |
| Neko | (oem-config still nukes on exit though, I gotta work out how to fix that, but we have a new uboot series coming out.. which will make flash-kernel work better...) | 18:01 |
| Neko | btw is the flash-kernel package owner in here | 18:01 |
| kgilmer_ | ogra, where can i get more info on livecd-rootfs? | 18:07 |
| kgilmer_ | the default google search isn't very enlightening. | 18:07 |
| TAsn | Hey guys, I can't find the SmartQ v7 in https://wiki.ubuntu.com/ARM/DeviceSupport but I remember reading somewhere (sorry, lost the link) that it does in fact work. Is this true? So, is there support? If so, in the form of a repository hosted somewhere? or do I have to compile everything on my own? Thanks. | 19:15 |
| ogra | berco, no | 19:43 |
| ogra | berco, console-kit cares for that since lucid | 19:44 |
| playya_ | what are the minimum disk requirements for an arm ubuntu with a tiny window manager (matchbox, unity) ? | 20:55 |
| Neko | for the whole unity desktop? | 21:06 |
| playya__ | i have to recreate my lvm partitions and maybe i can get enough space for an ubuntu | 21:07 |
| playya__ | but not high priority | 21:07 |
| playya_ | is ogra's build-arm-rootfs still usable for maverick? | 21:51 |
| ogra_ac | playya_, better use qemu-debootstrap --arch armel | 21:53 |
| playya_ | ok | 21:53 |
| ogra_ac | oh, wait, build-arm-rootfs ? | 21:53 |
| playya_ | yes | 21:54 |
| ogra_ac | no, use rootstock | 21:54 |
| playya_ | i think the resulting image might be to big and the pre's kernel is quite old (2.6.24) | 21:54 |
| playya_ | maybe i should wait for the pre plus | 21:55 |
| ogra_ac | doko, new ac100 image up if you want | 22:41 |
| ogra_ac | (with the battery spam patched out of the kernel now) | 22:41 |
| === JaMa is now known as JaMa|Zzzz | ||
| Neko__ | battery spam? :) | 22:45 |
| === ogra_ac_ is now known as ogra_ac | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!