| holstein | OvenWerks: but, i think it may be more clear that way | 03:12 |
|---|---|---|
| holstein | OvenWerks: if there were a meta that addressed that, and documentation.. | 03:12 |
| holstein | who knows | 03:12 |
| holstein | its so far from the way folks are used to using computers | 03:12 |
| holstein | folks *dont* buy the "apple osx audio production version".. or, "windows 10 with audio addon pack" or whatever | 03:13 |
| holstein | they just get the OS, get used to it, and buy the applications they want to use | 03:13 |
| holstein | not saying thats what i wish we were doing, just that its different | 03:13 |
| OvenWerks | holstein: I think we can say we are already beyond the first step. A person can just add the metas already. Plus we have an installer that tells a person which metas make sense. | 14:57 |
| OvenWerks | The next step is to roll in the installer we use on the ISO that allows the user to not install everything in the meta. | 14:58 |
| OvenWerks | I also think That a Jack install needs to make sure the user is in the audio group. This is not done now because the debian user is already a part of the audio group. the ubuntu package for jack needs to make sure. | 15:00 |
| OvenWerks | That might even beconsidered a bug with the ubuntu version of jack or with the user setup, thopugh the user setup not having audio group is ubuntu policy, so it is hard to call that a bug. | 15:03 |
| OvenWerks | finding yet another way to give users access to the system would be great. | 15:04 |
| OvenWerks | I feel that a jack install should just work. The user should not have to add themselves to a group, or even aknowledge a prompt to get it to work right as they do now. This is the biggest fail for just installing metas right now. | 15:08 |
| OvenWerks | I think that is one of the biggest things we get asked about all the time. | 15:10 |
| OvenWerks | The second niggest trouble area is that the jack2 install includes both jackd and jackdbus. | 15:11 |
| OvenWerks | *biggest | 15:11 |
| OvenWerks | We need to set things up so that only one of these will work. Our current ISO is set up to use jackdbus. The pulse module depend on it, qjackctl depends on it and some of the audio session managers depend on it. Yet almost all of the information out there documents using jackd instead. However as soon as jackd is started, qjackctl and PA no longer work right. | 15:14 |
| OvenWerks | Also, the jack libs that jack aware applications use will start jackd for the user if it is not already running without asking. I found this out when making a jack aware MIDI program. | 15:17 |
| OvenWerks | There are two solutions, one is to split the jackd2 package into two, one for jackd and the other for jackdbus. This will not happen. | 15:18 |
| OvenWerks | The other is to use system default (/etc/default) to point jackd at a script that looks to the user like jackd, but really is just a wrapper for jack_control. | 15:21 |
| OvenWerks | This would allow those who really do want everything jackd to change default and get the real thing as well as people who don't know still being able to use the documentation to learn jack | 15:23 |
| OvenWerks | Oops sorry, I guess I was looking for the /etc/alternatives directory. | 15:29 |
| OvenWerks | Using aternatives would mean changing the jack2 package, I don't know how easy this would be. Jackd would be a link to /etc/alternatives/jackd which would like to either the real jackd or a script that runs jack_control. | 15:37 |
| OvenWerks | Using /etc/cd /etc | 15:38 |
| OvenWerks | using /etc/profile line with alias jackd=jackd.script | 15:41 |
| OvenWerks | might work too. | 15:41 |
| OvenWerks | Both of these things could be controled by a Studio_controls application. | 15:43 |
| OvenWerks | Controls might also turn the pa jack bridge off and qjackctl dbus option off if the user wants to really use jackd. | 15:46 |
| OvenWerks | zequence: most of what I said above is for you too. | 15:46 |
| OvenWerks | I am thinking out loud, hoping for input. | 15:47 |
| OvenWerks | zequence: I think we have gone over this before to some extent, but, in the case of giving a user permission to use jack in an automated way, should all users get it? Our normal policy has been that Studio is a single user setup, but in the add meta to another DE that may not hold true. | 15:53 |
| OvenWerks | Also in a home system more than one person might use the system. It would be confusing that there is lots of applications in the menu that don't work right for some users. | 15:54 |
| OvenWerks | Perhaps our kernel could have "slacker" permissions in the realtime area? | 15:56 |
| OvenWerks | Or maybe a udev rule(s) to do the same thing? | 15:57 |
| OvenWerks | It is possible that the lowlatency kernel gets used in an internet server for VoIP like aterisk for example, so slack permissions there is not a good idea. | 15:59 |
| OvenWerks | Jack may be installed in a server as well, I would guess, so udev fiddles should be careful. | 16:03 |
| OvenWerks | The users group seems to be no more, or it is there but not used. SO the whole idea of groups seems to be going away | 16:07 |
| OvenWerks | is this no groups thing a ubuntu only thing, or is debian going the same path? | 16:08 |
| OvenWerks | zequence: another thought has occured to me. The PA-jack bridge gives RT errors. I wonder if pa itself does not llok for RT stuff, but the pa-jack bridge does because it expects jack to have it. Pulse is in the audio group, so it may be something else. In general, the pa-jack bridge is not something that is well tested for little things like that. it just works for the most part. I am wondering though if this is part of the reason it goe | 16:18 |
| OvenWerks | That may be fixed now. I don't see the PA errors in my latest install. | 17:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!