Just a note that the default F17 pulseaudio configuration supports jack bridging via dbus (/etc/pulse/default.pa).
### Automatically connect sink and source if JACK server is present .ifexists module-jackdbus-detect.so .nofail load-module module-jackdbus-detect .fail .endif
This is different to again to module-jack-sink.so/module-jack-source.so which is what some of us have been using up until now.
What that means is if jack-audio-connection-kit-dbus is on the spin by default, bridging is set up automatically.
This is something that needs to be considered carefully and I'd be interested in how well jackdbus is working for people. I was having random errors in the past with jackdbus hogging CPU with pulse. I will perform some more monitoring here, but it would be great to hear what others have experienced.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 31/05/12 08:43, Brendan Jones wrote:
Just a note that the default F17 pulseaudio configuration supports jack bridging via dbus (/etc/pulse/default.pa).
### Automatically connect sink and source if JACK server is present .ifexists module-jackdbus-detect.so .nofail load-module module-jackdbus-detect .fail .endif
This is different to again to module-jack-sink.so/module-jack-source.so which is what some of us have been using up until now.
What that means is if jack-audio-connection-kit-dbus is on the spin by default, bridging is set up automatically.
This is something that needs to be considered carefully and I'd be interested in how well jackdbus is working for people. I was having random errors in the past with jackdbus hogging CPU with pulse. I will perform some more monitoring here, but it would be great to hear what others have experienced.
Throwing in a large torch at fire here now ... do we really need pulseaudio? I mean, this is a multi-media production spin, filled with applications where Jack has become the standard - at least among the audio based applications.
I don't know how that jack/pulse bridge really works ... but if pulse really is needed, wouldn't it be better to write something which can completely replace the pulse libraries, and rather re-use just the API ... so that pulse based applications appears as those in/out sinks in Jack directly? This might be a rather long-term goal though.
This might be a better way to get better predictability in how the audio production applications would behave, still having a fallback for non-jack capable software.
Please educate me if I'm totally wrong here.
kind regards,
David Sommerseth
On 05/31/2012 03:25 PM, David Sommerseth wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 31/05/12 08:43, Brendan Jones wrote:
Just a note that the default F17 pulseaudio configuration supports jack bridging via dbus (/etc/pulse/default.pa).
### Automatically connect sink and source if JACK server is present .ifexists module-jackdbus-detect.so .nofail load-module module-jackdbus-detect .fail .endif
This is different to again to module-jack-sink.so/module-jack-source.so which is what some of us have been using up until now.
What that means is if jack-audio-connection-kit-dbus is on the spin by default, bridging is set up automatically.
This is something that needs to be considered carefully and I'd be interested in how well jackdbus is working for people. I was having random errors in the past with jackdbus hogging CPU with pulse. I will perform some more monitoring here, but it would be great to hear what others have experienced.
Throwing in a large torch at fire here now ... do we really need pulseaudio? I mean, this is a multi-media production spin, filled with applications where Jack has become the standard - at least among the audio based applications.
I don't know how that jack/pulse bridge really works ... but if pulse really is needed, wouldn't it be better to write something which can completely replace the pulse libraries, and rather re-use just the API ... so that pulse based applications appears as those in/out sinks in Jack directly? This might be a rather long-term goal though.
With pulseaudio-jack bridging, both are running. Pulseaudio simply redirects its output to jack's default system input ports.
This means applications which are not jack enabled will in most cases simply work. I regularly need to run applications for work (such as skype) and this seems to be a really stable solution.
Having said that, I'd really like one of the aims of the Spin be focussed on ease of configuration, and providing an easy way to disable pulseaudio completely should be considered.
This might be a better way to get better predictability in how the audio production applications would behave, still having a fallback for non-jack capable software.
Please educate me if I'm totally wrong here.
kind regards,
David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk/HcUcACgkQIIWEatLf4HeKFQCfeZY63NLf82/4ePLXKQBLUdky V+gAn2lrXHIsPPjVmCo/NfCYS0VA0FIu =fLRW -----END PGP SIGNATURE-----
On 05/31/2012 07:10 AM, Brendan Jones wrote:
On 05/31/2012 03:25 PM, David Sommerseth wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 31/05/12 08:43, Brendan Jones wrote:
Just a note that the default F17 pulseaudio configuration supports jack bridging via dbus (/etc/pulse/default.pa).
### Automatically connect sink and source if JACK server is present .ifexists module-jackdbus-detect.so .nofail load-module module-jackdbus-detect .fail .endif
This is different to again to module-jack-sink.so/module-jack-source.so which is what some of us have been using up until now.
What that means is if jack-audio-connection-kit-dbus is on the spin by default, bridging is set up automatically.
This is something that needs to be considered carefully and I'd be interested in how well jackdbus is working for people. I was having random errors in the past with jackdbus hogging CPU with pulse. I will perform some more monitoring here, but it would be great to hear what others have experienced.
Throwing in a large torch at fire here now ... do we really need pulseaudio? I mean, this is a multi-media production spin, filled with applications where Jack has become the standard - at least among the audio based applications.
I don't know how that jack/pulse bridge really works ... but if pulse really is needed, wouldn't it be better to write something which can completely replace the pulse libraries, and rather re-use just the API ... so that pulse based applications appears as those in/out sinks in Jack directly? This might be a rather long-term goal though.
With pulseaudio-jack bridging, both are running. Pulseaudio simply redirects its output to jack's default system input ports.
This means applications which are not jack enabled will in most cases simply work. I regularly need to run applications for work (such as skype) and this seems to be a really stable solution.
Having said that, I'd really like one of the aims of the Spin be focussed on ease of configuration, and providing an easy way to disable pulseaudio completely should be considered.
I think pulseaudio is here to stay and if there is still stuff that does not work correctly it should be fixed (as opposed to gutting the whole thing).
I would be opposed to having the pulse to jack bridge automatically kick in.
This should be certainly an option and would be very useful, but there should be an easy to use configuration setup where I can choose whether pulse automatically goes to jack or not (and for the Fedora Jam spin it should be off by default, I think). In the usage cases I manage you do not want that to be "on" by default. If you are in the middle of a mixing session or in a concert performance you do not want a random application that you forgot to turn off suddenly decide it is a good idea to warn the user about something with a nice chime sound...
-- Fernando
This might be a better way to get better predictability in how the audio production applications would behave, still having a fallback for non-jack capable software.
Please educate me if I'm totally wrong here.
kind regards,
David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk/HcUcACgkQIIWEatLf4HeKFQCfeZY63NLf82/4ePLXKQBLUdky V+gAn2lrXHIsPPjVmCo/NfCYS0VA0FIu =fLRW -----END PGP SIGNATURE-----
music mailing list music@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/music
On 06/01/2012 06:58 PM, Fernando Lopez-Lezcano wrote:
On 05/31/2012 07:10 AM, Brendan Jones wrote:
On 05/31/2012 03:25 PM, David Sommerseth wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 31/05/12 08:43, Brendan Jones wrote:
Just a note that the default F17 pulseaudio configuration supports jack bridging via dbus (/etc/pulse/default.pa).
### Automatically connect sink and source if JACK server is present .ifexists module-jackdbus-detect.so .nofail load-module module-jackdbus-detect .fail .endif
This is different to again to module-jack-sink.so/module-jack-source.so which is what some of us have been using up until now.
What that means is if jack-audio-connection-kit-dbus is on the spin by default, bridging is set up automatically.
This is something that needs to be considered carefully and I'd be interested in how well jackdbus is working for people. I was having random errors in the past with jackdbus hogging CPU with pulse. I will perform some more monitoring here, but it would be great to hear what others have experienced.
Throwing in a large torch at fire here now ... do we really need pulseaudio? I mean, this is a multi-media production spin, filled with applications where Jack has become the standard - at least among the audio based applications.
I don't know how that jack/pulse bridge really works ... but if pulse really is needed, wouldn't it be better to write something which can completely replace the pulse libraries, and rather re-use just the API ... so that pulse based applications appears as those in/out sinks in Jack directly? This might be a rather long-term goal though.
With pulseaudio-jack bridging, both are running. Pulseaudio simply redirects its output to jack's default system input ports.
This means applications which are not jack enabled will in most cases simply work. I regularly need to run applications for work (such as skype) and this seems to be a really stable solution.
Having said that, I'd really like one of the aims of the Spin be focussed on ease of configuration, and providing an easy way to disable pulseaudio completely should be considered.
I think pulseaudio is here to stay and if there is still stuff that does not work correctly it should be fixed (as opposed to gutting the whole thing).
I would be opposed to having the pulse to jack bridge automatically kick in.
This should be certainly an option and would be very useful, but there should be an easy to use configuration setup where I can choose whether pulse automatically goes to jack or not (and for the Fedora Jam spin it should be off by default, I think). In the usage cases I manage you do not want that to be "on" by default. If you are in the middle of a mixing session or in a concert performance you do not want a random application that you forgot to turn off suddenly decide it is a good idea to warn the user about something with a nice chime sound...
Sure. There's a bunch of stuff we can do the %post section of the install to tweak configuration. $HOME/.pulse is also somewhere where we can override these settings, but I'm still unsure of the limits of what we can and can't do in the kickstart.
Ideally something like this [1] that sits in the system tray would be awesome (this is from kxstudio's cadence program, not sure if ready for primetime - if not perhaps we can create something similar. I might set up a repo for evalution of kxstudio in any case)
[1] http://bsjones.fedorapeople.org/cadence-audio-config.png
Brendan
On 31 May 2012 14:25, David Sommerseth davids@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 31/05/12 08:43, Brendan Jones wrote:
Just a note that the default F17 pulseaudio configuration supports jack bridging via dbus (/etc/pulse/default.pa).
### Automatically connect sink and source if JACK server is present .ifexists module-jackdbus-detect.so .nofail load-module module-jackdbus-detect .fail .endif
This is different to again to module-jack-sink.so/module-jack-source.so which is what some of us have been using up until now.
What that means is if jack-audio-connection-kit-dbus is on the spin by default, bridging is set up automatically.
This is something that needs to be considered carefully and I'd be interested in how well jackdbus is working for people. I was having random errors in the past with jackdbus hogging CPU with pulse. I will perform some more monitoring here, but it would be great to hear what others have experienced.
Throwing in a large torch at fire here now ... do we really need pulseaudio? I mean, this is a multi-media production spin, filled with applications where Jack has become the standard - at least among the audio based applications.
I don't know how that jack/pulse bridge really works ... but if pulse really is needed, wouldn't it be better to write something which can completely replace the pulse libraries, and rather re-use just the API ... so that pulse based applications appears as those in/out sinks in Jack directly? This might be a rather long-term goal though.
This might be a better way to get better predictability in how the audio production applications would behave, still having a fallback for non-jack capable software.
Please educate me if I'm totally wrong here.
Most multimedia end-use stuff doesn't do Jack. If you don't support them then you make the spin much less usable for casual use alongside production (which might be what you want, but would be a big step). Reimplementing the Pulse API is a pretty big target and what would be the result? Another Pulse that bridges to Jack anyway? If you use jack-pulse bridging then you have a Jack system and still have pulse playback.
Can't say anything about the dbus bridging: not using F17 yet due to an unresolved preupgrade bug.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 31/05/12 16:15, Ian Malone wrote:
On 31 May 2012 14:25, David Sommerseth davids@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 31/05/12 08:43, Brendan Jones wrote:
Just a note that the default F17 pulseaudio configuration supports jack bridging via dbus (/etc/pulse/default.pa).
### Automatically connect sink and source if JACK server is present .ifexists module-jackdbus-detect.so .nofail load-module module-jackdbus-detect .fail .endif
This is different to again to module-jack-sink.so/module-jack-source.so which is what some of us have been using up until now.
What that means is if jack-audio-connection-kit-dbus is on the spin by default, bridging is set up automatically.
This is something that needs to be considered carefully and I'd be interested in how well jackdbus is working for people. I was having random errors in the past with jackdbus hogging CPU with pulse. I will perform some more monitoring here, but it would be great to hear what others have experienced.
Throwing in a large torch at fire here now ... do we really need pulseaudio? I mean, this is a multi-media production spin, filled with applications where Jack has become the standard - at least among the audio based applications.
I don't know how that jack/pulse bridge really works ... but if pulse really is needed, wouldn't it be better to write something which can completely replace the pulse libraries, and rather re-use just the API ... so that pulse based applications appears as those in/out sinks in Jack directly? This might be a rather long-term goal though.
This might be a better way to get better predictability in how the audio production applications would behave, still having a fallback for non-jack capable software.
Please educate me if I'm totally wrong here.
Most multimedia end-use stuff doesn't do Jack. If you don't support them then you make the spin much less usable for casual use alongside production (which might be what you want, but would be a big step).
Agreed.
Reimplementing the Pulse API is a pretty big target and what would be the result? Another Pulse that bridges to Jack anyway? If you use jack-pulse bridging then you have a Jack system and still have pulse playback.
As I understand it, the currently available pulse bridge requires a running pulseaudio daemon running. So you have this chain:
app -> pulseaudio lib -> pulseaudio daemon -> pulse bridge -> jackd
By writing a native pulse library which integrates directly with jack, you'll get:
app -> pulse/jack bridge API lib > jackd
Which means you should be able to get much more control over the applications using pulse. Each of the apps should then appear as separate jack sinks, which you can route more freely. And the pulse based applications might even have a lower latency, as the audio packets skips a "detour" to reach jackd. And this also helps avoid fiddling around with issues related to running both jackd and pulseaudio in parallel ... if jackd doesn't run before pulseaudio runs, pulse might have taken hardware in possession and so on.
But as you say, this is a pretty hefty target to stretch for. But if I'm not too far off, I think the end result will be easier to maintain and control. Except of having to follow the pulse API more closely.
kind regards,
David Sommerseth
-
Brendan Jones -
David Sommerseth -
Fernando Lopez-Lezcano -
Ian Malone