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
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.
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.
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.
-
Brendan Jones -
Christopher Antila