What is the policy on audio group? and, proposal of a new group for the jack audio server
Hi. I'm the project leader for Ubuntu Studio and a prospective Debian developer. My work tends to focus mostly on multimedia production related topics, and specifically audio production. My main objective right now is just to try making audio production easier for regular users, and this is still a big problem on most Linux based distributions. Some of this relates to the usage of audio group. First off, is there a clear policy on the use of audio group in Debian? I did find some explanations on the usage of it on this page, under 'Should users be in the "audio" group?' http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/PerfectSetup/, and from what I can determine, Debian would then fall under category 2 as explained in the text. Is that what Debian wants? I know that many distros do not use the audio group as default for users. I suspect for reasons as explained on this page https://wiki.ubuntu.com/Audio/TheAudioGroup. Audio group is also used by the jack audio server for granting realtime scheduling privilege to users. Packages jackd1 and jackd2 install a pam setting file which grants "rtprio" and "memlock" privilege to audio group. Package libffado2 installs a udev rules file granting audio group privilege to a set of firewire audio cards (which are primarily used with jack). This is quite a nice setup, since users are already in audio group and need only install jack in order to get the benefit of realtime scheduling. - This is however not a universal, standardized approach, since not all distros want the users to be in audio group. Usage of pam for granting realtime privilege *is* a standard approach though. It is what all audio production tuned distros do, and it is what people manually do on distros that doesn't provide it OOTB. The main difference is the group name used (in Ubuntu Studio, we also use the audio group - mainly because the Debian packages we import expect it). So, I would propose to use a new group, specifically for jack (and ffado). Why? If Debian adds such a group, and the Debian packages for jack and ffado make use of it, making ease of installation of Debian derived distros will greatly simplify and it would be more likely those distros would be willing to also add that group as a default group for users. At least, there would be no conflict, as is the case with audio group. And by that point, things actually do greatly simplify for regular users. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1414358356.2467889.183498341.324fe...@webmail.messagingengine.com
Re: What is the policy on audio group? and, proposal of a new group for the jack audio server
On Sun, Oct 26, 2014, at 11:36 PM, Marco d'Itri wrote:
> On Oct 26, Kaj Ailomaa wrote:
>
> > I did find some explanations on the usage of it on this page, under
> > 'Should users be in the "audio" group?'
> > http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/PerfectSetup/,
> > and from what I can determine, Debian would then fall under category 2
> > as explained in the text. Is that what Debian wants?
> Yes.
>
> > Package libffado2 installs a udev rules file granting audio group
> > privilege to a set of firewire audio cards (which are primarily used
> > with jack). This is quite a nice setup, since users are already in audio
> > group and need only install jack in order to get the benefit of realtime
> > scheduling.
> Debian users should not be in the audio group: if the devices are not
> already covered by the rules in /lib/udev/rules.d/71-seat.rules then
> they should be tagged with TAG+="seat" so that users on the local
> consoles will be able to access them..
Ok, so you are for removing audio group from user default groups?
I'm not very familiar with udev rules, but the rules for ffado point to
audio group.
The beginning of 60-ffado.rules (in package libffado2):
SUBSYSTEM!="firewire", GOTO="ffado_end"
# TC GROUP A/S
ATTR{vendor}=="0x000166", GROUP="audio", ENV{ID_FFADO}="1"
# Mark of the Unicorn, Inc. (aka MOTU)
ATTR{vendor}=="0x0001f2", GROUP="audio", ENV{ID_FFADO}="1"
Would these be able to be tagged with "seat" as you mention?
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/1414374505.2513381.183566945.64743...@webmail.messagingengine.com
Re: What is the policy on audio group? and, proposal of a new group for the jack audio server
On Mon, Oct 27, 2014, at 02:58 AM, Marco d'Itri wrote: > On Oct 27, Kaj Ailomaa wrote: > > > Ok, so you are for removing audio group from user default groups? > Eventually, yes. > So, who determined that audio group will not be used as a default user group in Debian, and when you say eventually, do you mean Debian 9? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1415541225.645217.188812509.7715a...@webmail.messagingengine.com
Re: What is the policy on audio group? and, proposal of a new group for the jack audio server
I would assume the way to go forward would be to report a bug on this? I have a faint memory of there already being one, but I couldn't find it anywhere. Also, my last bug report got closed - and I'm not even sure what to report it against (base?). Perhaps someone else would be more competent at writing one, or could provide some tips for me on how to do it? Seems to me there's somewhat an agreement on that audio group should stay, but "regular" user accounts should not be in it by default. This is the way many other distros do. Also, the main reason why I bring this up is on account of the jack audio server. The jackd1/jackd2 package assumes the user is a member of audio group, which is key in getting realtime privilege for the user who installs jack. Jack installs a file in /etc/security/limits.d, granting rtprio and memlock to audio group. Whenever I bring this up, someone tells me that we should use something else, like rt-kit, or using cgroups (which I have been experimenting with lately, but was unable to get to work for some reason - I can provide more info if someone is interested). Though this is a bit premature, until we can provide another solution, and if the user is made to not be default member of audio group, I would like it if there was a new group specifically for jack. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1415642631.1344497.189280829.4053f...@webmail.messagingengine.com
Bug#708476: ITP: pd-extended -- Extended version of puredata which recommends the installation of a large set of extra pd libraries, extensions and documentation.
Package: wnpp Severity: wishlist Owner: Kaj Ailomaa * Package name: pd-extended Version : 0.44 Upstream Author : Name * URL : http://puredata.info/ * License : BSD Programming Lang: (C, Tcl, Lua, puredata) Description : Extended version of puredata which recommends the installation of a large set of extra pd libraries, extensions and documentation. pd-extended is an extended version of puredata, with some gui enhancements among other things. It is fully compatible with puredata extra libraries, such as pd-zexy, pd-plugin, pd-pan, etc. All though it replaces puredata, it can be installed and run next to it. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130515234642.4669.70282.reportbug@melete.mousike
