[00:00] <knome> except that currently you might end up downloading/installing a lot of stuff you don't need
[00:03] <knome> i understand the selling point aspect, but it also means you need to maintain the config, run a lot more QA, partake in release related activities, specifically support the ISO...
[00:03] <knome> it's a lot for something that doesn't seem like an essential thing from where i stand
[00:06] <sakrecoer> as is now, one does have the option to install one, several or all the workflows..
[00:06] <sakrecoer> i'm not against your idea, i'm still processing it :)
[00:06] <knome> sure
[00:06] <knome> you could still do that even if you didn't have an ISO, as long as each workflow was one task
[00:07] <knome> and this is just an idea anyway - i'm not the one who will be taking care of that
[00:07] <knome> (there's enough work with xubuntu ;))
[00:07] <knome> but i thought i'd share the idea with you since it might lead you to a better place
[00:07] <knome> maybe that can be a lighter ISO or sth
[00:08] <sakrecoer> its highly appreciated knome :) i look forward to read zequence, OvenWerks and ross weight in on it :)
[00:08] <knome> but ultimately i think now is the time to try to cut down the extra maintaining stuff
[00:08] <knome> (all teams could do that tbh)
[00:09] <sakrecoer> considering the size of the team (at least from a mailing-list/IRC POV) that is a very good point
[00:09] <knome> the xubuntu team has always struggled with contributor amount too
[00:10] <knome> lately, i think we've been able to achieve even better stuff by making thigns smoother
[00:10] <sakrecoer> well, i think any volunteer based organisation strugle with that to some extend. at least when it comes to find regular and longterm contributors..
[00:10] <knome> of course
[00:11] <sakrecoer> i get the feeling you sort of cracked the desktop agnostic nut, but i might be blinded by lack of experience.
[00:12] <knome> that's one possibility
[00:12] <knome> the other possibility is what has been discussed before, eg. enabling the user to pick their DE during install time
[00:12] <knome> but ultimately, that's just EVEN MORE work :)
[00:12] <knome> because likely that would mean at least some config for each DE
[00:13] <sakrecoer> yeah, and also it implies having internetconnection during install..
[00:13] <knome> sure
[00:13] <knome> (and yeah, more to maintain in the installer too)
[00:13] <sakrecoer> i know it is getting common, internet in the air everywhere, but there are still MANY places where that is not a reality yet
[00:14] <knome> yes
[00:14] <sakrecoer> in a way, having an ISO makes ubuntustudio very inclusive.
[00:14] <knome> and tbh, there are many cases where you might have an internet connection, but it's easier to not
[00:14] <sakrecoer> :) yes
[00:14] <knome> of course
[00:15] <sakrecoer> but then again, having an iso kindof implies chosing a desktop
[00:15] <knome> one way to potentially fight that would be to provide ISOs that act as repostiories
[00:15] <knome> so basically just pull the packages into an ISO, no installer
[00:15] <knome> in a similar way to how you can upgrade your system now
[00:16] <knome> that could be workflow-based too, so you could download only the stuff you need
[00:16] <sakrecoer> wouldn't that be equal to having several iso's? one for system install, one for extra repo?
[00:16] <knome> the system installation iso could be the minimal ISO, eg. the general one
[00:17] <knome> the rest of the ISOs would be just "repositories", not needing the same level of QA stuff at all
[00:17] <knome> (and that is just if you want to support offline installs)
[00:21] <sakrecoer> it is a good thing to reduce download volumes anyways. unfortunately, it looks like the ISP market is starting to rationalise badnwidth for the end-user (as in x$/month for 20gb/month)
[00:22] <sakrecoer> i hope and wish we are not going there for landlines... but who know how long the land lines will be maintaned, looking at the desperate desires of ISP to make big$ by any mean necessary...
[00:24] <sakrecoer> its another debate i guess, but still, smaller download: faster download
[03:10] <zequence> sakrecoer_: knome: The idea of no ISOs is an old one. But, no matter the future, we will release 16.04
[03:10] <knome> of course
[03:10] <zequence> And, right now, it seems we have more interest, so I think it really depends on who wants to help out
[03:10] <knome> it would be silly not to release an LTS which is coming next
[03:11] <zequence> Yeah
[03:11] <zequence> As long as someone is willing to work on the ISO stuff, I guess it will be around
[14:14] <OvenWerks> http://linux-audio.4202.n7.nabble.com/Re-Updated-to-kernel-4-4-1-missing-module-snd-ice1712-gt-no-more-envy24-support-td98936.html#a98940
[14:14] <OvenWerks> zequence: is this true?
[14:19] <OvenWerks> if so zequence there are not many replacement cards... and the few that are around are not cheap. the ice1712 is a very common sound card still.
[14:20] <zequence> OvenWerks: Didn't know about that
[14:21] <zequence> I really don't follow kernel development much. 
[14:21] <zequence> We can change that config for our kernel
[14:21] <OvenWerks> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1534647
[14:21] <zequence> I'll look into it
[14:22] <OvenWerks> It looks like someone already has: "Given the mutual exclusivity of CONFIG_ZONE_DMA and CONFIG_ZONE_DEVICE, I've set CONFIG_ZONE_DMA=y for amd64 lowlatency and both i386 flavours ."
[14:23] <OvenWerks> The ice1712 will only work with the lowlatency kernel.
[14:23] <zequence> Yeah, that seems fine for us
[14:23] <zequence> And, they are working on a generic solution
[14:25] <OvenWerks> zequence: see comment 12
[14:26] <OvenWerks> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1534647/comments/12
[14:27]  * OvenWerks can't afford to spend $1k on a replacement PCIe sound card.
[14:30] <knome> if you were a ubuntu member, you might be able to get that paid from the community fund
[14:30] <knome> (just a tip)
[14:32] <OvenWerks> knome: the ice1712 sound cards are still in wide use in the audio and amature radio community. There is really no replacement for these cards. It is not just me. Nor is it a fix to fix me and not everyone else.
[14:33] <OvenWerks> Ubuntustudio is effectively broken without ice1712 support.
[14:34] <OvenWerks> on the up side... there may appear a RT kernel that gets support as the low latency kernel gets far away enough from main line anyway.
[14:37] <OvenWerks> knome: the USB "pro"audio cards have been troublesome and still do not get the performance of PCI(e) cards due to USB structure. USB2.0 audio support has been patchy from kernel to kernel as well.
[14:52] <knome> OvenWerks, fair enough, but the comment still stands; there will be people with those other cards in the future
[14:56] <OvenWerks> knome: true, from that perspective. AudioScience supports Linux pretty good as they cater to Broadcast where Linux use is a good segment of their business. RME maybe not so much. In truth, in the long run AoIP (aes67 or AVB), are the next thing.
[14:56] <knome> that just flew kilometers over my head
[14:56] <knome> so i'll just say
[14:57] <knome> yep
[14:57] <OvenWerks> :)
[14:59] <OvenWerks> knome: audioscience and RME are the only people I know who make PCIe audio cards (actually there is one other in the broadcast end, but not as linux friendly), but MOTU, focusrite and presonus all have AVB products out now. AVB means plug the audio IF into your ethernet port... probably a PCIe card because the one on the MB is not good enough.
[15:00] <knome> that was quite close to the first shot ;)
[15:00] <knome> but yeah, i get it now
[15:01] <knome> and while it links to existing network of thoughts... no, i still don't know what to do with that data
[15:01] <knome> :)
[15:04] <OvenWerks> knome: I am not sure I do either. I have gotten an Intel i210 ethernet card which has extra HW that allows audio sync over ethernet. Now to figure out the various bits to make it talk AVB.
[15:04] <knome> mhm
[15:05] <OvenWerks> knome: and it is (right now) just a collection of bits.
[15:06] <knome> while i'm "not interested" about hardware (in the sense that as long as it works, i'm good with it), i think it's nice to see different components being used for multiple uses or at least innovative uses
[15:07] <knome> another example that comes to my mind are those super small GPU-based computers
[15:07] <knome> that can't do anything but good for the industry
[15:07] <knome> (even if it might mean more work for linux developers making sure the hardware works as intended)
[15:07] <OvenWerks> :)
[15:08] <OvenWerks> in general GPU is good for Graphics and some desktop computing but is not low enough latency for audio.
[15:08] <OvenWerks> (DSP)
[15:09] <knome> sure
[15:09] <knome> for my audio purposes, i'm fine as long as i can playback music :P
[15:10] <knome> i kind of would like to be involved with creating some, but i just don't have enough time/motivation/skills
[15:10] <OvenWerks> the real problem for audio is that the PC hardware developers lowlatency is 30ms which is fine for your purposes :)  and skype.
[15:10] <knome> yep
[15:11] <OvenWerks> The OSx hw is designed for audio latency down to 1ms or so, PC hw can get down there, but it takes a lot of tweaking.
[15:11] <OvenWerks> (and being picky about what hw one buys in the first place)
[15:22] <knome> yeah..
[15:23] <knome> but linux-using people (know how to) do that already
[15:42] <OvenWerks> knome has not spent time helping people who do not know about that at all. Linux has gotten to that "just works" stage for many things. Lowlatency audio is not one of them. Pro Audio is not one of them :)
[15:46] <zequence> OvenWerks: Do you know a good solution for setting a default CPU governor?
[15:46] <zequence> I'm looking at adding that to -controls
[17:15] <OvenWerks> zequence: I would sugest looking through the Cadence code (also python I think).
[17:15] <zequence> Alright
[17:16] <OvenWerks> I used a small utility run from /usr/sbin that I set using pkexec to just run that would only change governor settings.
[17:16] <OvenWerks> utility=script
[17:18] <OvenWerks> I put a file in /usr/share/polkit-1/actions/ called net.ovenwerks.asmgov.policy that allowed amsgov to be run su with no passwd required.
[17:19] <OvenWerks> we would change that to org.ubuntustudio.*  :)
[17:22] <OvenWerks> zequence: check http://www.ovenwerks.net/paste/asmgov_policy for what is in that file. I think Cadence does a similar kind of thing.
[17:26] <OvenWerks> zequence: see http://www.ovenwerks.net/paste/asmgov for what I did in the file it points to. The sys/nosys stuff is probrbaly of no interest as the commands have changed with the move to systemd I would imagine. I prefer to have cron off while recording... just in case because there are some things that still cause xruns. I am told that a real RT kernel does not have this problem.
[17:28] <OvenWerks> zequence: while I am at it... 
[17:29] <OvenWerks> zequence: this is autojack http://www.ovenwerks.net/paste/autojack as it stands.
[17:31] <OvenWerks> In this form autojack looks for DEV device and starts it with jackdbus. It creates a jacksink/souce paclientwith the device name and connects them to system
[17:33] <OvenWerks> then it bounces through all the other devices and connects them using zita-ajbridge and creates dev named pa-jack bridges for each of those as well and connects them.
[17:36] <OvenWerks> If you wish to try it, it can be run from commandline after a fesh boot without harm. Do look at the system/DSP load with this running to see why I think this is a bad idea. Also note that this does only connect hw:devicename,0,0 It does not deal with hw:device,1 or whatever (though it would not be that hard) because of the same reason, it is not a good idea in my opinion.
[17:42] <zequence> OvenWerks: Thanks. Yeah, the PA bridge is not optimal. And, things may become a bit too complicated this time for doing anything else than starting jack and the bridge
[17:43] <zequence> I'll have a look at it
[17:43] <OvenWerks> zequence: there is no reason the DEV, EXTRA_C and EXTRA_P can not be fully qualified audio devices hda,2,1 or whatever
[18:19] <OvenWerks> zequence: in my asmgov_policy file I think the allow_gui">true< line is not needed. I can't remember if I had to have it in there because I was running it from a GUI or because I copied it from somewhere.
[18:20] <OvenWerks> anyway, if we can run without it, that would be better.
[19:10] <OvenWerks> it appears linux 4.4.0 kernel is not yet a part of ubuntustudio.
[20:05]  * OvenWerks likes the new (if it stays) window decoration style
[20:07] <OvenWerks> the "cutout" for the _ [] X icons at the top of the window makes it much easier to spot which window is in focus.
[20:08]  * OvenWerks finds the idea that there will only ever be one full sized window on a screen anoying.
[20:44] <OvenWerks> AcK! how do I turn the screen reader off????
[20:47] <OvenWerks> Hmm, the screen reader works very well  :)  but there seems to be no off button.
[20:48] <OvenWerks> I had to use kill to stop it.
[20:50]  * OvenWerks is questioning the switch to libc5 for a LTS
[20:50] <OvenWerks> So far things do seem to work though
[20:51] <knome> probably better do it now than support old stuff for 5 years
[20:52] <OvenWerks> knome: someone is doing a lot of work updating everything.
[20:52] <knome> many people are doing a lot of work :)
[20:52] <OvenWerks> but ya, I can see that too
[20:56] <OvenWerks> knome: It seems there is a boot option to start with upstart still, is that remaining for release?
[20:56] <knome> no idea
[22:22] <OvenWerks> zequence: running 16.04 right now, up graded to 4.4.0-4-lowlatency and the fix seems to have taken.
[22:24] <OvenWerks> mudita24 works fine.
[22:28] <OvenWerks> zequence: however, qjackctl has trouble with the systray. I normally set qjackctl up to start in the systray... when I do that, A) the systray icon does not appear and and the menu is blank. B) if I save it that way and reboot then start qjackctl, the whole desktop stops working... the mouse moves, but hover or click do not work untill I kill qjackctl. This means the menu does not work and none of the apps do. But C-A-F1 does (thankfully
[22:45] <OvenWerks> Bug #1546328
[22:46] <OvenWerks> Anyone testing 16.04 version of Studio should check this and click on the this bug affects me too link.
[22:46] <OvenWerks> (if you have the same problem.)
[22:47] <OvenWerks> knome: have there been any other systray problems with xfce in 16.04?
[22:48]  * OvenWerks thinks I had a similar problem in lubuntu... but wasn't sure if it was just the low memory used. (less than 256M ram)
[22:49] <OvenWerks> This bug in Studio shows up with 8Gram so I guess it affects lubuntu too.
[22:49] <knome> i haven't heard of anything very weird, but you should really talk with flocculant 
[22:50] <flocculant> I read OvenWerks talking about that 20 mins ago - didn't strike any chords with me
[22:51] <OvenWerks> flocculant: I wonder if qjackctl was built with qt5
[22:51] <flocculant> not a clue :)
[22:51] <OvenWerks> it has been buildable with 4 or 5 for a while now.
[22:52] <flocculant> other than guessing it's something to do with jack - have no idea whatqjackctl is tbh
[22:54] <OvenWerks> flocculant: the systray part has nothing to do with systray though. I was just wondering if systray had changed or Qjackctl.