| === frewsxcv94709 is now known as frewsxcv94040 | ||
| === smartboyhw_ is now known as smartboyhw | ||
| len-dt | smartboyhw, You might notice that there are some "ubuntustudio" that are not included in an install. | 15:59 |
|---|---|---|
| len-dt | Normally we don't recommend adding all of them to another install, just the needed work flows. | 16:00 |
| len-dt | Just so you know Ubuntu or Xubuntu plus all the ubuntustudio metas does not = Ubuntustudio the way a fresh install would do. | 16:02 |
| smartboyhw | len-dt, well then..... we never recommended installing it on a Mac anyway did we? Thx for the info though. | 16:06 |
| len-dt | smartboyhw, Even then, I would start with the desktop of choice and add workflows. | 16:07 |
| len-dt | I don't know that there is a lowlatency kernel for the mac. | 16:08 |
| persia | Which mac? Recent macs running Ubuntu use the same x86_64 lowlatency as any other recent intel chip. Most of the same patches probably also apply for powerpc, but there may not be enough users to be worth the maintenance. OS X kernels are just one flavour, which is reported to be sufficiently low latency when running Logic. | 16:10 |
| len-dt | persia, Ya, I was just reviewing a converstion on #ubuntustudio | 16:11 |
| persia | Ah, no worries then :) | 16:11 |
| len-dt | even with a pc mapping all our metas over something else mostly doesn't do the same as an install | 16:12 |
| persia | I think we ought consider that a bug, personally. It used to work that way. | 16:12 |
| len-dt | I think zequence is working on that actually as part of the controls package. | 16:14 |
| len-dt | There are some things though that with xfce panels and such where once the user has logged in, the way they are is set and changing the system default won't change them. | 16:15 |
| len-dt | Eye candy stuff, backgrounds and themes mostly | 16:16 |
| zequence | I think the mac version is not very different from the regular version. Mac has some HW oddities, but CPU is the same | 16:16 |
| persia | That probably needs lots of low-level work: I know that for the GNOME stuff, there was a lot of work done to cause the user session to be generated from a mix of system and user data. | 16:16 |
| persia | Having just gotten a new mac, I tell you that it's not any different, aside from the hardware selection. | 16:17 |
| zequence | I've only tried using mac with linux. Puredyne ran pretty well on a macbook | 16:17 |
| persia | The reason for the different downloadable images is because Apple EFI and other folks UEFI are rather incredibly different. | 16:17 |
| persia | Someone might get around to writing code that works well by default on both and lets you boot a CD/DVD/USB, but perhaps not very soon. | 16:18 |
| len-dt | persia, nice to know. So it is the grub part of things then so a kernel should work? | 16:18 |
| persia | Yeah, kernels are the same. grub is even the same. | 16:18 |
| persia | For both mac and non-mac, one can run either grub-pc (BIOS) or grub-efi (EFI/UEFI): the issues all surround the grub-install script. | 16:19 |
| zequence | I think the main practical difference in adding all our metas, compared to a fresh studio install, is that the user will not end up in audio group after adding metas, which should not happen anyway. And, many user settings are already done, especially if you use another UI, so the experience using the desktop is not going to be identical | 16:19 |
| === jta is now known as jta_afk | ||
| persia | Needing to be in the audio group is a bug. | 16:20 |
| persia | Certainly the desktop experience would be different, but we should be able to provide standards-compliant stuff to give a broadly similar experience. | 16:21 |
| len-dt | it keeps the server people happy... | 16:21 |
| persia | Mind you, environments like unity that fail to comply with XDG menu spec are probably harder to support. | 16:21 |
| persia | Hrm? How? | 16:21 |
| len-dt | There are some people who do not want the user to have rt access by default so if not audio group something else to do the same thing. | 16:22 |
| persia | But aren't we supposed to use rtkit for that? | 16:23 |
| zequence | Not according to Paul Davis | 16:23 |
| zequence | I'm happy with whatever works well, and is the easiest to implement | 16:24 |
| zequence | Fromt he user point of view, I mean | 16:24 |
| zequence | On Debian, the user is a member of audio group by default | 16:24 |
| zequence | Probably not a good thing, but that is how it is | 16:24 |
| zequence | pulseaudio is also a member of audio group | 16:25 |
| persia | Used to be that way in Ubuntu as well. Most of the things that required that stopped. | 16:25 |
| zequence | I think different people are using the same group for different things | 16:25 |
| len-dt | I think slackware is set up that way too | 16:25 |
| persia | The last remaining item is limits.conf, which rtkit *should* solve. | 16:25 |
| * len-dt remebers it used to be | 16:25 | |
| persia | but perhaps rtkit isn'T rich enough, or something. I haven't been following the debate. | 16:25 |
| zequence | jackd now installs /etc/security/limits.d/audio.conf, which contains the two important lines | 16:26 |
| zequence | So, on Debian, that is enough to get realtime privilege. However, there's another problem too | 16:26 |
| zequence | firewire devices cannot be accessed without being in audio group | 16:26 |
| zequence | udev rules | 16:26 |
| persia | That's easy to fix. | 16:27 |
| persia | I think pitti is part of udev upstream now, and I know he was one of the folk interested in dropping the audio group requirement. | 16:27 |
| zequence | /lib/udev/rules.d/60-ffado.rules | 16:28 |
| len-dt | it has to work with all the variants not just debian derivatives. As jack is developed for linux and the author is not likely to be happy doing it more than one way. | 16:29 |
| persia | Heh, of course :) No reason we can't ask for changes upstream. | 16:30 |
| zequence | I don't know why one way is better than the other. I don't care. From our point of view, it's a matter of getting Debian/Ubuntu system infrastructure working to our benefit, no matter which solution, as long as it works | 16:31 |
| len-dt | I agree, the admin should be able to chose if the user has rt or not. so long as that happens, what does it matter? | 16:32 |
| zequence | It's too much for me personally to find out, and work on, so I'm not touching it, at least for now. But, it would be nice if a user could just install jackd, and get realtime privilege | 16:33 |
| zequence | Without further setting up | 16:33 |
| len-dt | yup | 16:34 |
| persia | Hrm. The ffado udev rules specifying the audio group don't seem to have been uploaded with a bug reference. I wonder why they are that way. | 16:34 |
| len-dt | That doesn't work without jack anyway. | 16:35 |
| zequence | jack works without realtime privilege, but the firewire driver won't work without the user being a member of audio group | 16:36 |
| persia | zequence: Because of the udev rules, or also because of something else? | 16:36 |
| zequence | persia: I guess the udev rules are what makes it possible for users to access the firewire devices, through the group membership. | 16:39 |
| zequence | So, if one is member of audio group, that is enough to run jackd with firewire. To get realtime privilege, you add the two lines to /etc/security/* | 16:40 |
| persia | Ah, OK. I'm guessing leftovers from the every-firewire-device-is-a-hard-drive-and-must-be-restricted-to-root-access philosophy then. | 16:40 |
| persia | Now that we have juju, we can probably relax that (but I should go verify the state of juju in our kernels before I say that) | 16:40 |
| persia | Ah, found it: https://blueprints.launchpad.net/ubuntu/+spec/multimedia-platform-n-pro-audio-secured | 16:42 |
| zequence | We should probably talk with David about that then | 16:43 |
| persia | Yep :) | 16:44 |
| persia | From the last note at the end, I get the impression that adding the memlock support is feasible (although I don't think it's done, based on my search results). | 16:45 |
| persia | If so, that drops the limits.d/audio.conf requirement. | 16:45 |
| persia | Indeed, the audio group requirement for the firewire udev rules is about protecting raw1394 access to the underlying device (which could be used to compromise filesystems) | 16:47 |
| len-dt | It looks to me like not much has moved. FW development in general seems to be quite slow. Reading about FW to ALSA it seems the idea is dead right now. | 16:51 |
| persia | OK, 60-ffado.rules can be changed to not use the audio group: it ought use the ACL mechanism: see 70-acl.rules. | 16:53 |
| persia | Mind you, this would only let the currently-logged-in user access the firewire devices. Does this seem like it might be an issue? | 16:53 |
| len-dt | We set up pulse to be user centric so it should be ok. | 16:54 |
| persia | Cool. | 16:54 |
| zequence | For low latency audio, I don't see much point in multiuser access to the same device | 16:55 |
| len-dt | It should be session centric. There are some problems for people who run audio from terminal... IE sight impared. | 16:55 |
| len-dt | Setting up a session than the same user can use from more than one VT at the saem time is "interesting" | 16:56 |
| persia | heh. indeed :) | 16:56 |
| len-dt | The answer that google shows ends up with a pile og dbus tasks running when really only two are needed (maybe one) | 16:57 |
| zequence | One audio server at a time though | 16:58 |
| len-dt | I did manage to get it to work with just the two though. | 16:58 |
| persia | If someone else wants to investigate ffado's need for the audio group before I get to it: apparently Fedora has it working without: presumably one could install in a VM and check the file layout. | 16:58 |
| len-dt | Yup one audio server. but a lot of the jack CLI utils use dbus. | 16:58 |
| persia | Right: finished confirming: we are entirely using the new firewire stack, so the permissions concerns with the old one are no longer relevant. | 17:01 |
| zequence | persia: Are you talking about the change from the old stack to the new stack in the kernel, that happened around 2010? | 17:03 |
| zequence | I think Ubuntu moved to the new stack with 10.10 | 17:03 |
| persia | Um, it's not done yet. | 17:03 |
| persia | it's still possible to generate raw1394 drivers (or was last I knew) | 17:03 |
| zequence | I'm not that good with terms, but I think raw1394 is the old one, and firewire_something, is the new one | 17:04 |
| persia | And the reports I see are that the v4l2 driver is still missing, as well as fixes to libavformat and pwlib (pwlib will likely never happen) | 17:04 |
| persia | Right. *1394 are the old interfaces, and firewire-* are the new ones. | 17:05 |
| persia | (well, sbp2 was also one of the old interfaces, but that's just a detail) | 17:05 |
| zequence | persia: Yea, so from what I understand, we've been using the new stack since 10.10. The udev rules appeared at that time too | 17:05 |
| persia | That said, in Ubuntu, it appears our kernels don't build the old interfaces. | 17:05 |
| persia | (which means that we just handle video cameras badly) | 17:06 |
| zequence | The udev rules are what makes the current setup work, while for the old one, Ubuntu Studio used to grant access to all firewire devices through video | 17:06 |
| zequence | through the video group | 17:06 |
| zequence | There were no udev rules preinstalled in the past, as they are now, on all Debian systems (I think) | 17:07 |
| persia | Well, a mix of the "audio" and "video" groups, but yeah. | 17:07 |
| persia | No, it was more hardcoded, and what wasn't often used hal. | 17:07 |
| zequence | So, I don't think Fedora is doing it differently. In fact, i think they are doing it the same way, but one would need to confirm that | 17:09 |
| persia | According to the upstream firewire wiki, Fedora is using ACLs for some firewire device types, but I think that's just using 70-acl.rules, from what I see. | 17:10 |
| persia | But I'd need to test to find out what is different, and whether the GROUP= entry could be dropped from 60-ffado.rules with that before being confident. | 17:10 |
| zequence | Ah, this line: SUBSYSTEM=="firewire", ENV{ID_FFADO}=="1", TAG+="udev-acl" | 17:12 |
| zequence | And there are a few others, concerning firewire | 17:12 |
| persia | Right. I believe that is supposed to interact with session management and grant the currently active user access to the device. | 17:14 |
| persia | What I don't know is whether we have polkit configured in such a way that it just works. | 17:15 |
| persia | Indeed, we do *not* have the necessary polkit rules to automagically do the right thing. | 17:19 |
| persia | So, two bugs: | 17:19 |
| persia | 1) rtkit needs to grow memlock support | 17:20 |
| persia | 2) we need polkit rules to grant access to ffado devices | 17:20 |
| persia | Unless someone knows another reason we need an "audio" group? | 17:20 |
| zequence | And rtprio? | 17:23 |
| zequence | Or, does rtkit handle that differently? | 17:23 |
| === jta_afk is now known as jta | ||
| persia | Seems it's configued in rtkit: http://git.0pointer.de/?p=rtkit.git;a=blob;f=README | 17:26 |
| zequence | ever felt like if you didn't have so many problems to solve, you'd have more time to solve problems? | 18:03 |
| astraljava | zequence: I can't hear you over the problems I'm trying to solve. | 18:12 |
| zequence | astraljava: I'm sorry. Busy strangling my mouse. Get back to you when I have audio | 18:16 |
| zequence | It's great when you google for help and find a very helpful wiki page you forgot you wrote only a week ago | 21:25 |
| Len-nb | :) | 21:45 |
| === jta is now known as jta_afk | ||
| zequence | Interesting, though 4 years old talk about linux kernel development. Some facts about speed of changes, and who contributes https://www.youtube.com/watch?feature=player_detailpage&v=L2SED6sewRw#t=51s | 22:12 |
| zequence | I wasn't aware of the fact that amateurs, at least then, where the biggest group of contributors, if you didn't count companies as one single group, but separate per company | 22:15 |
| zequence | And, also back then, Canonical were not contributing much at all | 22:16 |
| zequence | I think probably it might be worthwhile looking at maintaining a linux-rt | 22:20 |
| zequence | Or.. I don't know. I need to think more about that | 22:21 |
| len-dt | zequence, it may be more worthwhile figuring out why new kernels have poor low latency performance. | 22:32 |
| len-dt | Maybe there are new additions/settings that could be changed/bypassed in the low latency/rt kernel | 22:32 |
| zequence | len-dt: I was looking at the kernel versioning, and realized the odd versions are not maintained for any long periods of time. They reach EOL pretty quickly. Yet, Ubuntu always uses whatever kernel is the latest | 22:36 |
| zequence | the rt patch is added to all the even numbers | 22:36 |
| zequence | Those which are maintained for a longer time | 22:36 |
| zequence | Somehow, I would have thought it would make sense for Ubuntu to only use the even numbers, and that would also have made it practical when maintaining a -rt kernel | 22:37 |
| zequence | Of course, one could always keep one, which was not the same version as the stock kernel | 22:37 |
| zequence | So, if Ubuntu would go with say, 3.5, the -rt kernel could be 2.4 | 22:37 |
| zequence | 3.4* | 22:37 |
| zequence | I haven't yet tried patching the Ubuntu kernel with the rt patch. I actually only built an rt for the first time today | 22:38 |
| zequence | As the -rt patch is meant for the vanilla kernel, there could be problems | 22:39 |
| len-dt | zequence, I think there is good reason for using only even numbered kernels | 22:39 |
| len-dt | Would it be possible to set US to look at only even numbers in case generic was installed too? | 22:40 |
| len-dt | What versions does -server use? | 22:40 |
| * len-dt thinks he would prefer even kernels in a server for sure | 22:42 | |
| zequence | len-dt: There's no server flavor anymore | 22:42 |
| len-dt | I thought ubuntu was trying to have a server market... something that pays. | 22:43 |
| zequence | ..wait | 22:43 |
| zequence | I must have misunderstood something | 22:44 |
| zequence | It's the same versioning anyway | 22:44 |
| len-dt | Even in LTS? | 22:45 |
| zequence | No server flavor since 12.04 | 22:45 |
| len-dt | Or are the LTS ones always even? | 22:45 |
| zequence | https://wiki.ubuntu.com/Kernel/Dev/Flavours | 22:45 |
| zequence | lucid had a preempt flavor. Didn't know that. Only mad64 | 22:48 |
| zequence | amd64* | 22:48 |
| len-dt | what has happened with the LMMS thing? (swept under the carpet?) | 22:49 |
| zequence | len-dt: Perhaps just that no one has taken a decision for adding it | 22:50 |
| len-dt | But no talk either | 22:50 |
| len-dt | I could add it to the seeds and see what happens... | 22:50 |
| zequence | I think we covered just about everything on the mail list | 22:50 |
| zequence | I'm for adding it | 22:51 |
| len-dt | If I add it to the seeds now it should show tomorrow either in or broken build. | 22:51 |
| * len-dt is willing to take the blame | 22:51 | |
| len-dt | I'll comment the commit as "trial only" | 22:52 |
| zequence | Nah, just add it | 22:52 |
| len-dt | will do. | 22:53 |
| zequence | I think it fills a workflow that other applications don't really do | 22:53 |
| zequence | It's not like there are 5 other apps like LMMS out there | 22:53 |
| zequence | And to those who say it's buggy. Well, so are most of the other apps as well | 22:54 |
| Len-nb | gmorgan tries to do much the same. | 22:55 |
| zequence | If we all had magic wands, maybe we could solve those problems pretty quick | 22:55 |
| Len-nb | or got paid... just for this | 22:55 |
| zequence | gmorgan was new to me, but that looks more like a tracker than a sequencer | 22:56 |
| zequence | Ah, musical patterns | 22:57 |
| * Len-nb is going to eat | 22:57 | |
| zequence | Never seen an interface like that one before | 22:58 |
| zequence | the mail accounts request seems to have been accepted | 23:23 |
| zequence | I must be doing something wrong. I can't get an rt kernel built with decent performance | 23:47 |
| zequence | There's a new config for the rt patch though, called CONFIG_PREEMPT_LAZY | 23:48 |
| zequence | But, disabling it doesn't help much | 23:51 |
| zequence | I'm getting worse performance than from -lowlatency | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!