User1: except that currently you might end up downloading/installing a lot of stuff you don't need
User1: 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...
User1: it's a lot for something that doesn't seem like an essential thing from where i stand
User2: as is now, one does have the option to install one, several or all the workflows..
User2: i'm not against your idea, i'm still processing it :)
User1: sure
User1: you could still do that even if you didn't have an ISO, as long as each workflow was one task
User1: and this is just an idea anyway - i'm not the one who will be taking care of that
User1: (there's enough work with xubuntu ;))
User1: but i thought i'd share the idea with you since it might lead you to a better place
User1: maybe that can be a lighter ISO or sth
User2: its highly appreciated knome :) i look forward to read zequence, OvenWerks and ross weight in on it :)
User1: but ultimately i think now is the time to try to cut down the extra maintaining stuff
User1: (all teams could do that tbh)
User2: considering the size of the team (at least from a mailing-list/IRC POV) that is a very good point
User1: the xubuntu team has always struggled with contributor amount too
User1: lately, i think we've been able to achieve even better stuff by making thigns smoother
User2: well, i think any volunteer based organisation strugle with that to some extend. at least when it comes to find regular and longterm contributors..
User1: of course
User2: i get the feeling you sort of cracked the desktop agnostic nut, but i might be blinded by lack of experience.
User1: that's one possibility
User1: the other possibility is what has been discussed before, eg. enabling the user to pick their DE during install time
User1: but ultimately, that's just EVEN MORE work :)
User1: because likely that would mean at least some config for each DE
User2: yeah, and also it implies having internetconnection during install..
User1: sure
User1: (and yeah, more to maintain in the installer too)
User2: i know it is getting common, internet in the air everywhere, but there are still MANY places where that is not a reality yet
User1: yes
User2: in a way, having an ISO makes ubuntustudio very inclusive.
User1: and tbh, there are many cases where you might have an internet connection, but it's easier to not
User2: :) yes
User1: of course
User2: but then again, having an iso kindof implies chosing a desktop
User1: one way to potentially fight that would be to provide ISOs that act as repostiories
User1: so basically just pull the packages into an ISO, no installer
User1: in a similar way to how you can upgrade your system now
User1: that could be workflow-based too, so you could download only the stuff you need
User2: wouldn't that be equal to having several iso's? one for system install, one for extra repo?
User1: the system installation iso could be the minimal ISO, eg. the general one
User1: the rest of the ISOs would be just "repositories", not needing the same level of QA stuff at all
User1: (and that is just if you want to support offline installs)
User2: 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)
User2: 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...
User2: its another debate i guess, but still, smaller download: faster download
User3: sakrecoer_: User1 The idea of no ISOs is an old one. But, no matter the future, we will release 16.04
User1: of course
User3: And, right now, it seems we have more interest, so I think it really depends on who wants to help out
User1: it would be silly not to release an LTS which is coming next
User3: Yeah
User3: As long as someone is willing to work on the ISO stuff, I guess it will be around
User4: 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
User4: User3 is this true?
User4: 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.
User3: User4 Didn't know about that
User3: I really don't follow kernel development much.
User3: We can change that config for our kernel
User4: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1534647
User5: Launchpad bug 1534647 in mudita24 (Ubuntu Xenial) "Collateral damage due to kernel configuration change enabling CONFIG_ZONE_DEVICE (Kernel 4.4 amd64)" [Undecided,New]
User3: I'll look into it
User4: 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 ."
User4: The ice1712 will only work with the lowlatency kernel.
User3: Yeah, that seems fine for us
User3: And, they are working on a generic solution
User4: User3 see comment 12
User4: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1534647/comments/12
User5: Launchpad bug 1534647 in mudita24 (Ubuntu Xenial) "Collateral damage due to kernel configuration change enabling CONFIG_ZONE_DEVICE (Kernel 4.4 amd64)" [Undecided,New]
 * OvenWerks can't afford to spend $1k on a replacement PCIe sound card.
User1: if you were a ubuntu member, you might be able to get that paid from the community fund
User1: (just a tip)
User4: User1 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.
User4: Ubuntustudio is effectively broken without ice1712 support.
User4: 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.
User4: User1 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.
User1: OvenWerks, fair enough, but the comment still stands; there will be people with those other cards in the future
User4: User1 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.
User1: that just flew kilometers over my head
User1: so i'll just say
User1: yep
User4: :)
User4: User1 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.
User1: that was quite close to the first shot ;)
User1: but yeah, i get it now
User1: and while it links to existing network of thoughts... no, i still don't know what to do with that data
User1: :)
User4: User1 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.
User1: mhm
User4: User1 and it is (right now) just a collection of bits.
User1: 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
User1: another example that comes to my mind are those super small GPU-based computers
User1: that can't do anything but good for the industry
User1: (even if it might mean more work for linux developers making sure the hardware works as intended)
User4: :)
User4: in general GPU is good for Graphics and some desktop computing but is not low enough latency for audio.
User4: (DSP)
User1: sure
User1: for my audio purposes, i'm fine as long as i can playback music :P
User1: i kind of would like to be involved with creating some, but i just don't have enough time/motivation/skills
User4: the real problem for audio is that the PC hardware developers lowlatency is 30ms which is fine for your purposes :)  and skype.
User1: yep
User4: 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.
User4: (and being picky about what hw one buys in the first place)
User1: yeah..
User1: but linux-using people (know how to) do that already
User4: knome has not spent time helping people who do not know about adam66@example.net. 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 :)
User3: User4 Do you know a good solution for setting a default CPU governor?
User3: I'm looking at adding that to -controls
User4: User3 I would sugest looking through the Cadence code (also python I think).
User3: Alright
User4: I used a small utility run from /usr/sbin that I set using pkexec to just run that would only change governor settings.
User4: utility=script
User4: 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.
User4: we would change that to org.ubuntustudio.*  :)
User4: User3 check http://www.ovenwerks.net/paste/asmgov_policy for what is in that file. I think Cadence does a similar kind of thing.
User4: User3 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.
User4: User3 while I adam66@example.net...
User4: User3 this is autojack http://www.ovenwerks.net/paste/autojack as it stands.
User4: 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
User4: 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.
User4: 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.
User3: User4 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
User3: I'll have a look at it
User4: User3 there is no reason the DEV, EXTRA_C and EXTRA_P can not be fully qualified audio devices hda,2,1 or whatever
User4: User3 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.
User4: anyway, if we can run without it, that would be better.
User4: it appears linux 4.4.0 kernel is not yet a part of ubuntustudio.
 * OvenWerks likes the new (if it stays) window decoration style
User4: the "cutout" for the _ [] X icons at the top of the window makes it much easier to spot which window is in focus.
 * OvenWerks finds the idea that there will only ever be one full sized window on a screen anoying.
User4: AcK! how do I turn the screen reader off????
User4: Hmm, the screen reader works very well  :)  but there seems to be no off button.
User4: I had to use kill to stop it.
 * OvenWerks is questioning the switch to libc5 for a LTS
User4: So far things do seem to work though
User1: probably better do it now than support old stuff for 5 years
User4: User1 someone is doing a lot of work updating everything.
User1: many people are doing a lot of work :)
User4: but ya, I can see that too
User4: User1 It seems there is a boot option to start with upstart still, is that remaining for release?
User1: no idea
User4: User3 running 16.04 right now, up graded to 4.4.0-4-lowlatency and the fix seems to have taken.
User4: mudita24 works fine.
User4: User3 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
User4: Bug #1546328
User5: bug 1546328 in qjackctl (Ubuntu) "Systray option does not work." [Undecided,New] https://launchpad.net/bugs/1546328
User4: Anyone testing 16.04 version of Studio should check this and click on the this bug affects me too link.
User4: (if you have the same problem.)
User4: User1 have there been any other systray problems with xfce in 16.04?
 * 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)
User4: This bug in Studio shows up with 8Gram so I guess it affects lubuntu too.
User1: i haven't heard of anything very weird, but you should really talk with flocculant
User6: I read OvenWerks talking about that 20 mins ago - didn't strike any chords with me
User4: User6 I wonder if qjackctl was built with qt5
User6: not a clue :)
User4: it has been buildable with 4 or 5 for a while now.
User6: other than guessing it's something to do with jack - have no idea whatqjackctl is tbh
User4: User6 the systray part has nothing to do with systray though. I was just wondering if systray had changed or Qjackctl.
ubuntustudio-devel
Ubuntu IRC