12:40 p.m.
Hi Jorn
saw your email to the spins list - that's great. Also good to know that
our conservative estimate for the review deadline was exactly that - we
have 3 more weeks than we bargained for.
I just wanted to list a few items that need clarification from the Spins
team that are really outside my knowledge:
1 kernel parameters ( threadirqs in our case) how (can?) we add them to
the Live system and on install?
2 is it possible to modify sysconfig files in / owned by other packages?
- ie. changing the default values in /etc/pulse/daemon.conf or
/etc/pulse/default.pa might be advantageous.
3 is it possible to change/set config items in /home/<installed_user> ?
(e.g. /home/<user/.pulse - which would be a solution if (2) is not possible)
4 adding items to /etc/xdg/autostart (to autostart apps by default for
all users).
5 (related to #4) can we drop files into ~/.config/autostart as part of
the install process for the default user?
6 and which if any of these things can we do for the Live user?
The autostart questions arise from me considering having a DBUS enabled
qjackctl launch on login, configured to autostart jack (this requires
modifying the users qjackctl settings in $HOME). Pulseaudio shold
release the device and bridging should just work with the
module-jackdbus-detect, although I'm finding it a bit flaky here. Of
course none of this addresses selecting the default audio device etc etc.
I'm sure more questions will come up - I'm really just thinking out
loud. If for example none of these things are possible, we really would
have to develop a standard alone app to configure this stuff with the
user interactively.
Anyway, food for thought.
Brendan
PS. I will get kxstudio cadence up to my repo soon.
PPS. I think I'll forward this to the music list
2:07 p.m.
Hi:
On 13 June 2012 13:40:35 Brendan Jones wrote:
Hi Jorn
saw your email to the spins list - that's great. Also good to know that
our conservative estimate for the review deadline was exactly that - we
have 3 more weeks than we bargained for.
I just wanted to list a few items that need clarification from the Spins
team that are really outside my knowledge:
1 kernel parameters ( threadirqs in our case) how (can?) we add them to
the Live system and on install?
2 is it possible to modify sysconfig files in / owned by other packages?
- ie. changing the default values in /etc/pulse/daemon.conf or
/etc/pulse/default.pa might be advantageous.
3 is it possible to change/set config items in /home/<installed_user> ?
(e.g. /home/<user/.pulse - which would be a solution if (2) is not
possible)
4 adding items to /etc/xdg/autostart (to autostart apps by default for
all users).
5 (related to #4) can we drop files into ~/.config/autostart as part of
the install process for the default user?
6 and which if any of these things can we do for the Live user?
The autostart questions arise from me considering having a DBUS enabled
qjackctl launch on login, configured to autostart jack (this requires
modifying the users qjackctl settings in $HOME). Pulseaudio shold
release the device and bridging should just work with the
module-jackdbus-detect, although I'm finding it a bit flaky here. Of
course none of this addresses selecting the default audio device etc etc.
It's touch-and-go for me too. I can do it on my laptop, but not my desktop.
Either way, poorly functioning software isn't really our concern. This is
Fedora, where we release things before they're 100% stable, so our users can
help with testing and reporting bugs.
I know it's annoying sometimes, but it's part of the Fedora Project
philosophy.
Once we get the Fedora Audio Spin up and running, maybe, hopefully, we can
provide the necessary packages for CentOS 7 when it's released, and that will
be stable and happy.
I'm sure more questions will come up - I'm really just
thinking out
loud. If for example none of these things are possible, we really would
have to develop a standard alone app to configure this stuff with the
user interactively.
I believe a stand-alone configuration app should be on our horizon no matter
what. If the kxstudio 'cadence' app works, at least... otherwise we should do
it eventually.
People disagree about what "choice" means in relation to open-source software.
At minimum, our technical notes for the release should specify which non-
default settings the Spin uses; ideally, we'll also have an easy way for users
to change those settings to whatever they wish.
Anyway, food for thought.
Brendan
PS. I will get kxstudio cadence up to my repo soon.
PPS. I think I'll forward this to the music list
The more stuff that gets on the list, the better. Also, the more opinions, the
better. That means you, people!
Christopher.
2:56 p.m.
On 06/14/2012 09:07 PM, Christopher Antila wrote:
Hi:
On 13 June 2012 13:40:35 Brendan Jones wrote:
> Hi Jorn
>
> saw your email to the spins list - that's great. Also good to know that
> our conservative estimate for the review deadline was exactly that - we
> have 3 more weeks than we bargained for.
>
> I just wanted to list a few items that need clarification from the Spins
> team that are really outside my knowledge:
>
> 1 kernel parameters ( threadirqs in our case) how (can?) we add them to
> the Live system and on install?
>
> 2 is it possible to modify sysconfig files in / owned by other packages?
> - ie. changing the default values in /etc/pulse/daemon.conf or
> /etc/pulse/default.pa might be advantageous.
>
> 3 is it possible to change/set config items in /home/<installed_user> ?
> (e.g. /home/<user/.pulse - which would be a solution if (2) is not
> possible)
>
> 4 adding items to /etc/xdg/autostart (to autostart apps by default for
> all users).
>
> 5 (related to #4) can we drop files into ~/.config/autostart as part of
> the install process for the default user?
>
> 6 and which if any of these things can we do for the Live user?
>
> The autostart questions arise from me considering having a DBUS enabled
> qjackctl launch on login, configured to autostart jack (this requires
> modifying the users qjackctl settings in $HOME). Pulseaudio shold
> release the device and bridging should just work with the
> module-jackdbus-detect, although I'm finding it a bit flaky here. Of
> course none of this addresses selecting the default audio device etc etc.
It's touch-and-go for me too. I can do it on my laptop, but not my desktop.
Either way, poorly functioning software isn't really our concern. This is
Fedora, where we release things before they're 100% stable, so our users can
help with testing and reporting bugs.
One thing that has been clouding the issue is that F17 is currently
shipping a buggy Jack Control API due to a GCC 4.7 bug. This results in
somewhat unintended behaviour for Jack, and has been known to cause
Jackdbus to segfault. Whilst an update is imminent, I encourage anyone
who's wants to play around with this to stuff now download the jack
source RPM and compile it with -O0.
I've since been running this recompiled Jack from login with
pulse-bridging using default pulse config for well on 16 hours now with
no Xruns/messages, although I must admit have not done any hardcore
audio work in that time.
Is your laptop F16 perchance?
I know it's annoying sometimes, but it's part of the Fedora Project
philosophy.
Once we get the Fedora Audio Spin up and running, maybe, hopefully, we can
provide the necessary packages for CentOS 7 when it's released, and that will
be stable and happy.
> I'm sure more questions will come up - I'm really just thinking out
> loud. If for example none of these things are possible, we really would
> have to develop a standard alone app to configure this stuff with the
> user interactively.
I believe a stand-alone configuration app should be on our horizon no matter
what. If the kxstudio 'cadence' app works, at least... otherwise we should do
it eventually.
Well, KXStudio upstream is planning a rewrite in Python 3 - I haven't
got my hands on any source to play with yet, so its a bit of an unknown.
I don't expect the current publicly available source to be updated from
here on - but its a great reference source in any case,
People disagree about what "choice" means in relation to open-source software.
At minimum, our technical notes for the release should specify which non-
default settings the Spin uses; ideally, we'll also have an easy way for users
to change those settings to whatever they wish.
> Anyway, food for thought.
>
> Brendan
>
> PS. I will get kxstudio cadence up to my repo soon.
> PPS. I think I'll forward this to the music list
The more stuff that gets on the list, the better. Also, the more opinions, the
better. That means you, people!
Absolutely! Would love to hear more about how people manage their own
audio requirements.
Christopher.
6:17 p.m.
On 14 June 2012 15:56:31 Brendan Jones wrote:
>>
>> The autostart questions arise from me considering having a DBUS enabled
>> qjackctl launch on login, configured to autostart jack (this requires
>> modifying the users qjackctl settings in $HOME). Pulseaudio shold
>> release the device and bridging should just work with the
>> module-jackdbus-detect, although I'm finding it a bit flaky here. Of
>> course none of this addresses selecting the default audio device etc
>> etc.
>
> It's touch-and-go for me too. I can do it on my laptop, but not my
> desktop. Either way, poorly functioning software isn't really our
> concern. This is Fedora, where we release things before they're 100%
> stable, so our users can help with testing and reporting bugs.
One thing that has been clouding the issue is that F17 is currently
shipping a buggy Jack Control API due to a GCC 4.7 bug. This results in
somewhat unintended behaviour for Jack, and has been known to cause
Jackdbus to segfault. Whilst an update is imminent, I encourage anyone
who's wants to play around with this to stuff now download the jack
source RPM and compile it with -O0.
I've since been running this recompiled Jack from login with
pulse-bridging using default pulse config for well on 16 hours now with
no Xruns/messages, although I must admit have not done any hardcore
audio work in that time.
Is your laptop F16 perchance?
Both my machines are. I think my issue on the desktop is either in SELinux or
PAM, but I haven't had time to sort through it. I like to run my regular user
accounts in the user_u context, which rarely works by default (although it's
been getting better). As a huge generalization, it seems like the more an
application is developed commercially, the less well it cooperates with
SELinux.
Does anybody have advice on JACK + user_u in SELinux?
What's even worse is GCC bugs... because *everything* is involved.
Christopher.
4345
days inactive
4346
days old
3 comments
2 participants
participants (2)
-
Brendan Jones -
Christopher Antila