=== lilstevie|ZNC is now known as lilstevie [06:17] ogra, around/awake yet ? :) [06:18] He's typically a couple more hours. [06:18] persia, ahh ok, thanks :) [06:20] Find yourself at a loss during the pause-between-cycles? [06:21] persia, not at all :) plenty todo wrt unity-efl [06:21] persia, but, I do need to discuss something with him [06:21] Ah, I can't help with that then. [06:21] hehe yea [06:45] ogra, when you get online, please drop me a PM. Need to discuss a few things with ya, thanks :) [07:49] sebjan: Do you know who Misael Lopez Cruz is? [08:07] 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] sebjan: Does he still work for TI? [08:08] sebjan: I'm wondering if it's worth asking him to the session [08:11] lag: I don't know... best to ask Liam or Margarita [08:11] Sure, thanks === hrw|gone is now known as hrw [08:33] ehlo # === lilstevie is now known as lilstevie|ZNC [09:08] ogra: hi... fyi: just sent you an email... [09:47] vstehle: http://gitorious.org/croco [10:11] vstehle what do you want to know about it? === XorA|gone is now known as XorA [10:46] hi [10:47] 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:48] kornel`, What question would you ask if someone replied "Yes" to that? [10:49] is it possible to encode a live stream with an arm (with neon) processor realtime? and if so, what quality? [10:50] depends on cpu, method used [10:50] i would use arm cortex a8 [10:51] how much does dsp matters? [10:51] I'm not sure our encoders are NEON-enabled [10:51] kornel`: there is no such cpu as "arm cortex a8" [10:51] kornel`, DSP only matters if there are kernel drivers or encoder-specific drivers for that DSP. [11:01] ndec, and i answered it :) [11:02] ok thanks for answers [11:02] 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:03] persia: right i will buy some and triing :) thanks! [11:04] 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:38] persia: yeah, like nvidia saying they don't need neon because their soc is awesome :P [11:39] armin76, might be though: doesn't it support CUDA or something? [11:39] cuda on arm? weird [11:40] 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:44] vstehle: distcc will do work [11:45] hrw: I thought about that; less setup on PC, but more intrusive on package (need to override the compiler command, I guess). [11:48] or add one dir to PATH [11:49] armin76, Why? the code runs on the GPU anyway: CPU architecture ought be irrelevant. [11:57] * hrw -> food [12:00] 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] vstehle: You can use the hardening-wrapper trick to workaround this limitation [12:01] persia: start with mx51_defconfig and add compile-in support for the efikamx [12:01] amitk, So I don't care about any of the options that were set on the Netwalker for the old kernel/ [12:01] s:/:?: [12:02] persia: since all the HW doesn't yet work, no we don't care about the netwalker options ATM. [12:03] 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:07] persia: you'll get serial and ethernet now. The linaro kernel might get the mmc/sd patches too. Wifi is WIP. [12:08] Oh. Since my hardware has no serial or ethernet, that's not very useful. [12:10] persia: what wifi does it have? [12:14] armin76, I'm not sure precisely: something that uses "ks7010_sdio" [12:16] yuck [12:16] Why? [12:16] just curious [12:16] No, why "yuck"? [12:16] ah, its a renesas chipset [12:17] And this is bad because ... ? [12:17] 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] didn't know that renesas did wifi chips :) [12:18] persia: ks7010_sdio is kernel module? [12:18] hrw, No, kernel module is ks79xx_sdio [12:19] 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:20] persia: probably not, just wait some more to get the rest of the patches in place.. [12:21] 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:53] ogra: does the ac100 have a temperature sensor? === 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 [14:55] Hmm [14:56] I've been looking whether extras.ubuntu.com is disabled on ARM or not [14:56] it seems not [14:56] does someone confirm that extras.ubuntu.com shows up in sources.list after an Ubuntu install on ARM? [14:56] It isn't in the preinstalled images sources.list, just the live images. [14:57] And yes, I see it on dove. [14:58] GrueMaster: Does it work when you apt-get update? [14:58] GrueMaster: I'd expect some APT errors [14:59] Yes, I get errors. [14:59] GrueMaster: ah, is this reported somewhere already? [14:59] Apparently, it isn't limited to armel. It was discussed a few days ago on #u-release. [14:59] 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] GrueMaster: Ok thanks [15:00] o/ [15:00] lag, isnt it in 1h ? [15:01] UTC != GMT [15:01] (unless date -u lies to me) [15:01] oh, you sheduled it for GMT ? [15:01] * ogra thought he read UTC [15:01] Same thing [15:01] It will be hosted in #ubuntu-arm on freenode @ 15:00 UTC. [15:01] I forget we're in GMT+1 [15:02] ogra@osiris:/var/build/images$ date -u [15:02] Di 12. Okt 14:01:59 UTC 2010 [15:02] right [15:02] Bloodly British and their stupid saving hrs [15:03] heh === zyga is now known as zyga-afk === hrw|afk is now known as hrw [15:52] lag, do you have a build with the changes from liam ? [15:53] ogra, you get my email ? [15:53] ogra: Nope [15:53] Bit late to ask now [15:58] devilhorns, yes, need to talk with davidm [15:58] ogra, ok, no problem :) [16:00] Let's try this again ... [16:00] o/ [16:01] o/ [16:01] o/ [16:01] o/ [16:01] o/ [16:01] \o [16:01] We have an intruder [16:01] ;) [16:01] ;) [16:01] lrg: ? [16:02] * ogra is here [16:02] lag: here [16:02] Then we shall begin [16:02] Firstly we need to get everyone up to speed [16:03] I'm guessing lrg knows the most about this [16:03] Care to give us a rundown? [16:03] do we have rama here ? [16:03] Not seen [16:03] Here [16:04] rsrimushnam: Welcome [16:04] perfect :) [16:04] ... [16:04] ogra: Care to start us off? [16:06] 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] I thought we had sound via ALSA? [16:06] there are a) the backend routes not properly set by default [16:06] b) alsa seems to have issues [16:07] (i discussed with crimsun last night and he pointed me to a bug i noted into our bug) [16:07] b might be solved by the SRU crimsun plans [16:07] lag, we do but thats just through a slightly better hack [16:07] 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:08] ogra: care to expand on (b) [16:08] though as i understand it, my hack will turn into the default in future alsa (using the init subdir) [16:08] (b) is a libalsa issue is it not [16:08] Do you have the bug number to hand? [16:08] lrg, i cant expand much more than whats written on the bug, he just told me it would very likely improve things [16:08] bug 652035 [16:08] 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:09] seems some of the parsing isnt done right [16:09] there is an upstream fix and an additional fix crimsun added [16:09] i wish he could be here now, since he does most of the ubuntu alsa maintenance [16:09] It sounds like there are more issues than meets the eye [16:09] but it sadly collides with his work hours [16:10] Why do these work on other systems and not OMAP4? [16:10] lag, well, the bug only explains why i have to call alsactl init manually [16:10] which is anyway not the target we want to achieve [16:10] Is alsa-utils script call at all? It seems this script resets alsa values and has some cases based on platforms [16:11] berco, yes, it is called properly [16:11] and as i said above, the future of alsa seems to be to use these init scripts [16:11] but I don't know if it is called before SDP4430.conf is read... [16:11] it could overwrite SDP4430, right? [16:12] berco, i didnt use SDP4430.conf at all [16:12] after boot i have the right mixer settings using my way [16:12] 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] but no sound until i call aslactl init [16:12] diwic, so that could be the reason why the extra alsactl init is needed then [16:13] i.e. my scrip should work fine with that fix [16:13] but thats only half the solution [16:13] 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] ogra, Which init script is your script? [16:13] persia, the one attached to our bug [16:13] https://bugs.edge.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/637947/comments/24 [16:13] and [16:13] 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:14] https://bugs.edge.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/637947/comments/25 [16:14] berco, well, my script has two probs [16:14] a) these scripts want more info which the driver doesnt expose atm so we cant really differ between different omap4 boards [16:15] which is indeed bad unless the blaze uses exactly the same setup [16:15] Ah, OK. I thought it was something different :) [16:15] and b) more seriously HDMI doesnt get initialized and exposed to pulse [16:15] imho b) is only solvable through SDP4430.conf [16:15] but that could be a massively simpler one if it goes hand in hand with my init script [16:16] since we dont need to set volumes from the .conf [16:16] for a) we would need to extend the driver to expose more than just the card name [16:17] if you look at /usr/share/alsa/init/hda you can see how you can set different mixers based on the board [16:18] but we would need a mixername [16:18] note that i also havent tried the fix from bug 652035 yet, all this is based on assumptions [16:18] ogra: I could also add the machine name etc SDP4430/Panda/Blaze into the card name for (a) [16:18] 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] Is b) only soluable through SDP4430.conf? Can't we hint it by providing more inputs to pulse's module-udev-detect? [16:18] lrg, yeah, that would be good [16:19] I have HDMI working from PA [16:19] persia, its about outputs :) [16:19] 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] it's justa a matter of creating a PA profile (which I'm working on at this moment) [16:19] ogra, Right, so we expose more data in /sys/ that udev and pulse use to set the outputs. [16:19] abduenas, We're looking at autodetection solutions only. [16:19] we want either a selectable output in the audio prefs (with a default to analog) or a mirrored output [16:19] i'd say [16:20] I think the regular pulse output UI is fine. Let's not fuss with that. [16:20] abduenas, we cant touch pulse config [16:20] persia, yes, its fine and i saw hdmi exposed in it [16:20] persia, there are already mixer profiles for other cards in the default config [16:20] PA profile has nothing to do with touching pulse default.pa config [16:20] thats what i mean by selectable output [16:20] 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:21] rsrimushnam, right, so selectable with default to analog it is [16:21] 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] persia, upstream ships with files for e g native-instruments-audio8dj.conf and a few others [16:21] diwic, Yep. [16:21] 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:22] tw_, Are you able to wait ~45 minutes? [16:22] tw_: #beagleboard [16:22] tw_: #beagle [16:22] Even [16:22] Yes [16:22] Why? [16:22] tw_, If the folks in #beagle can't help, ask us again then, and we'll help. [16:22] thats bad [16:23] dont point him to #beagle [16:23] they dont use ubuntu usually [16:23] * persia will help tw elsewhere: please continue the sound meeting [16:23] tw_ I'll talk to you via other means - bear with me [16:23] btw: I am using one of the new BB_xm boards. [16:23] 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:24] where would that pa pfrofile go ? [16:24] /usr/share/pulseaudio/alsa-mixer/profile-sets [16:24] and an udev rule to go with it [16:24] 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] hmm [16:24] diwic: PA autodetection is wrong, we must be more explicit [16:25] diwic, how do you make sure that doesnt collide with the already existing udev rule ? [16:25] Did anyone ever get module-udev-detect working? Last I saw, folks were still hardcoding the modules for pulse. [16:25] lrg, can you elaborate? [16:25] persia, yes, my init script works without any extras [16:25] but with the above limitations [16:25] With regular default.pa? [16:25] yes [16:26] Oh, cool. [16:26] no changes to pulse at all [16:26] just the one line change to 00main and the script in place [16:26] diwic: auto detection depends on PA making guesses about the underlying audio hardware. [16:26] and the nasty extra alsactl init call [16:26] Ah, so comment 13 wasn't wrong after all. [16:26] ogra: it's one line in 00main + one omap4 file, right? [16:27] persia, yes, thats what made me develop that script [16:27] berco, xactly [16:27] no further changes [16:27] berco and I had thought that was wrong after some experimentation, leading to the SDP4430.conf route [16:27] lrg, so then we must trace down where PA guesses wrong and evaluate what to do in each particular case [16:27] if you then call aslactl init at some point after boot sound works fine through analog [16:27] wondering if we don't want to use udev as much as possible to avoid multiple conf files to maintain [16:28] udev does its job already [16:28] 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] with the init scrip the mixers are all set properly right after boot (and without asound.state file in place) [16:28] diwic, We'd do that in /usr/share/pulseaudio/alsa-mixer/paths/*, right? [16:29] lrg, Do we expect UCM by February? [16:29] well, as i understood crimsun UCM is whgat these init scripts are [16:29] or at lest the start of UCM [16:29] persia: yes, we are pshing Jaroslav to move it to his master branch ins alsa-lib.git [16:29] persia, those provide input for the probing as well as being a poor man's UCM, yes [16:30] Let's design a UCM-based solution then, and use that for Natty then. === zyga-afk is now known as zyga [16:30] persia: please everyone feel free to mail Jaroslav on UCM progress on alsa-dev. this may speed up progress [16:30] persia, we need a solution this week [16:30] lrg, but UCM or not, having uniform control names is still a good thing [16:30] And provide a pulse profile for maverick users. [16:30] persia, i dont care about natty [16:31] the SRU needs to be in before friday [16:31] ogra, But you will, so I'll care for you today :) [16:31] natty is well ... natty [16:31] diwic: uniform control names can apply to some audio hardware but unfortunately not all :( [16:32] * persia owns some hardware that would have difficulty with uniform control names [16:32] lrg, so if this particular hardware can't have standard control names, we write a pa profile to compensate? [16:33] lrg, assuming UCM is not available [16:33] diwic: yes, agreed [16:34] So, pulseaudio-profile for maverick and UCM for natty? [16:34] hrm [16:34] We'll still have 652035 though. [16:34] Has anyone tried the proposed SRU on an omap4 board with the alsa init script? [16:35] not yet [16:35] will the pulse profile help to initialize the right backend routing ? [16:35] nop [16:35] * ogra doesnt belive it scratches more than the surface [16:35] right [16:36] The pulse profile will tell pulse the control names to use. [16:36] so that doesnt help at all [16:36] Are you saying the HDMI out isn't even initialised with the init script? [16:36] oh, you mean only for adding HDMI ? [16:36] i understood as a general solution for the problem [16:37] I think there is some confusion about the "backend routing", what is that really about? [16:37] Right. Complete maverick solution is 652035 fix + alsa init script + pulse profile [16:37] diwic, adding the right codec to the control [16:37] 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] persia, ah, now i understand [16:39] kgilmer: hi here [16:39] diwic, currently alsa device 0,0 points to a null sink [16:39] by default === miguel is now known as Guest56473 [16:39] ogra, can all subdevices be used in parallel? [16:40] i dont know [16:40] or does the hw just support one stream at a time? [16:40] i'm really no audio guy, only worked into that during last week :) [16:40] i think it shoudl support more [16:40] lrg, ^ [16:40] HW supports multiple streams [16:40] 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] rsrimushnam, Can you confirm that? [16:40] but one of lrg or rsrimushnam should be able to answer [16:40] It can support more than one stream. But not necessarily all simultaneously. [16:41] rsrimushnam, Do we need to worry about how many it can support at once? [16:41] at kjourlald [16:41] ogra: UCM will export this multiple stream info to PA too [16:41] PA profile can also tell PA about the other hw devices [16:42] worry from what respect? [16:42] abduenas, that was my thought as well [16:42] rsrimushnam, Limit the number of simultaneous streams in the UI or something. [16:43] hi hrw :) [16:43] 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] hrw, i'm curious how rootstock differs from oe? does rootstock run entire build on arm via qemu? [16:44] rsrimushnam, That's easlier then. Thanks. [16:44] kgilmer_: it just uses packages from feeds + some mangling [16:44] so does the driver "probe" the codec and construct devices appropriately? Or are the subdevices hard-coded in the driver? [16:45] The subdevices appear to be constructed by the alsa init script [16:45] 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:46] Yes. [16:46] 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] abduenas is working on it now. [16:46] actually the PA guys are willing to include that on PA package, as native-instruments-audio8dj.conf [16:46] persia, the init script as posted in comment #25 does not add any subdevices? [16:47] hrw, packages = binary packages? [16:47] berco, I think ogra said that he didn't need SDP4430.conf with the init script. [16:47] persia, could you point me to that init script? [16:47] abduenas: ok, I see. That's fair [16:48] diwic, Then I'm mistaken. [16:48] persia, right [16:48] kgilmer_: yes [16:48] diwic, the scripts simply connect backends to frontends. [16:48] diwic, its attached to the bug [16:48] persia: I agree. Just wanted to make sure we discard this approach of SDP4430.conf [16:48] where do the binary packages get generated hrw? [16:48] ogra, so it is the #25 comment attachment? [16:48] diwic, right together with the change to 00main [16:48] (from 24) [16:49] kgilmer_: ah that your gentoo roots... [16:49] 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] they are apparently not since oyu need that script [16:49] nothing is hardcoded in the driver. [16:49] kgilmer_: in debian (and derived) binary packages are built by builddeamons [16:49] they FE and bE are initialised and left for userspace to connect. [16:50] mpoirier, who decides that 0,0 is a null sink and 0,7 (?) is HDMI? [16:50] e g [16:50] hrw, ah ic. those biuld daemons are running on target architecture or they are cross compiling? [16:50] ogra: so for the init script, will it be a udev rule? [16:50] kgilmer_: target - only native builds are done [16:50] berco, there is a udev rule already [16:51] 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] interesting hrw [16:51] diwic: the pcm mappings are done in the machine driver [16:51] have a look at sdp4430.c [16:51] berco, you only need to dump the script into /usr/share/alsa/init/ [16:51] ogra: oops, sorry. Thought alsactl init was still missing [16:51] * kgilmer_ sees a chicken and egg problem. [16:51] berco, right [16:51] kgilmer_: you mean "bootstrap" problem? [16:52] berco, but thats only to actually init, the mixers are all set right already and properly routed [16:52] yeah hrw [16:52] berco, the hope is that the aösa-lib fix solves the needed init [16:52] ogra: missed that one :). Now I understand the #652035 need :) [16:53] :) [16:53] so just waiting for rsrimushnam profile and we can test :) [16:54] rsrimushnam: when do you think you can provide us a profile-set to test? [16:54] sorry, most likely to be abduenas [16:54] we have something started already but we are still having issues with it. abduenas can elaborate [16:54] who provides this file [16:54] kgilmer_: both distros did bootstrap long time ago [16:55] fyi: I need to drop off in 5 minutes... [16:55] rsrimushnam: abduenas: I think we just need to get a rough idea of the timeframe [16:55] i'm just missing the udev rule in /lib/udev/rules.d/90-pulseaudio.rules to be able to read omap3.conf [16:55] but i'm udev nubee [16:56] abduenas, ugh, a udev rule for pulse ? [16:56] 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] sorry meant to say omap4.conf (or wahtever) [16:56] abduenas: don't hesitate to come to this channel and ask for help. If we can we will help [16:56] diwic, Why does it need to be different than what we do for headset/HDMI for anything else? [16:56] lag: are you taking a note of any actions here btw ? [16:57] I wasn't no [16:57] (irclogs.ubuntu.com can help if it's not being done in realtime) [16:57] abduenas, are you sure that is used at all when pulse runs on a per user base ? [16:57] ogra: this udev rule already exists. [16:57] persia: I'm forgetful ;) [16:57] (which is the default in ubuntu) [16:57] I don't think we have a meeting bot in here [16:57] 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] berco, right, but i think only if pulse runs as a system daemon it is used [16:58] ogra: I see. [16:58] 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] berco, i'm not sure though [16:58] berco, abduenas, that should be heavily tested [16:58] diwic, Aha. OK. I guess I've not actually used PA with my harder-to-define cards. [16:58] i'm able to use it on per-user basis [16:58] persia: No, it's okay :) [16:59] abduenas, thanks that helps :) [16:59] I we'll have to have a wash-up when the meeting has finished [16:59] Who's doing what etc [16:59] so who is fixing the driver side ? [16:59] lag, It's also worth separating into two discussions moving forward: maverick hacks and natty solution. [17:00] ogra: what part of the driver ? [17:00] to expose the board name [17:00] the name ? [17:00] ah, ok - me :) [17:00] :) [17:00] cool :) [17:00] like in the hda init file [17:00] i'm happy to add my init file to alsa-libs in an SRU [17:00] and the one line change to 00main [17:00] 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]