Ok, quick restatement of the problem:
How does one get Pd to just run in GNU/Linux for casual/sporadic use cases? Like 1 fire up Pd to patch an idea with Firefox/music player/other stuff sitting in the background 2 audio from online tutorial while patching in Pd with audio 3 some dude screwing around in Ubuntu with it, learns enough to get interested in fairly low latency to process some guitar sounds, possibly live
Cases 1 and 2 could benefit from having a PulseAudio backend in Pd, but case 3 would still be a pain because at the point that the guitarist cares about latency he/she is back to screwing around with audio settings (either directly through ALSA or with JACK). (If I'm wrong and Pulse can cover use case 3 I'd like to hear about it, but from what I've read Pulse is not designed with realtime audio processing as a goal.)
So, I'm curious about this: http://trac.jackaudio.org/wiki/JackDbusPackaging
Specifically the "D-bus only JACK" route. _If_ it works reliably (and of course that's a big if) then it gives the best of both worlds: all cases 1,2, and 3 above are covered by the JACK server automatically starting and Pulse getting out of the way for it. Moreover, Pulse clients get routed to JACK with what I take are "sane" defaults. So, if you have Pd running through JACK with this setup and then you open up a youtube video in Firefox, Pulse will automagically make a connection to JACK for it and (I'm guessing) hook it up to the output.
Any thoughts on this? I'm thinking if we could build up a body of knowledge on this approach it would be the easiest way to get worry-free audio setups with GNU/Linux distros that wouldn't give new users headaches. Plus it would scale up: if they learn and care about insanely low latencies, they are already using JACK so it's just a matter of firing up qjackctl or whatever and configuring the audio server they've been using.
Anyway I'll do some testing with it on Debian Wheezy over the next month. If anyone wants to try on other distros that'd be helpful (Linux Mint, Ubuntu, etc.)
Best, Jonathan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-05-28 07:08, Jonathan Wilkes wrote:
Ok, quick restatement of the problem:
How does one get Pd to just run in GNU/Linux for casual/sporadic use cases? Like 1 fire up Pd to patch an idea with Firefox/music player/other stuff sitting in the background 2 audio from online tutorial while patching in Pd with audio 3 some dude screwing around in Ubuntu with it, learns enough to get interested in fairly low latency to process some guitar sounds, possibly live
Cases 1 and 2 could benefit from having a PulseAudio backend in Pd, but case 3 would still be a pain because at the point that the guitarist cares about latency he/she is back to screwing around with audio settings (either directly through ALSA or with JACK). (If I'm wrong and Pulse can cover use case 3 I'd like to hear about it, but from what I've read Pulse is not designed with realtime audio processing as a goal.)
what works for me so far is: - - run jack as the native backend on my desktop (jackd gets autostarted at login, and is running throughout my session) - -- obviously Pd will always use the jack backend - - run pulseaudio *on top of jack*. - -- thus any pulseaudio-aware application (like firefox) can simply play back - -- i can route pulseaudio-apps into Pd (not that i ever needed this "in real life")
i really think that this is the way to go: have any consumer-framework sit on top of a "pro" framework, rather than the other way around (e.g. have pulseaudio provide a virtual alsa-device)
setting up was pretty easy by installing the "pulseaudio-module-jack" (on debian),and uninstalling all the other pa backends.
So, I'm curious about this: http://trac.jackaudio.org/wiki/JackDbusPackaging
Specifically the "D-bus only JACK" route. _If_ it works reliably (and of course that's a big if) then it gives the best of both worlds: all cases 1,2, and 3 above are covered by the JACK server automatically starting and Pulse getting out of the way for it. Moreover, Pulse clients get routed to JACK with what I take are "sane" defaults. So, if you have Pd running through JACK with this setup and then you open up a youtube video in Firefox, Pulse will automagically make a connection to JACK for it and (I'm guessing) hook it up to the output.
Any thoughts on this?
personally i would prefer to *not* pull in additional dependencies if possible. afair, d-bus is notorious for pulling in an entire desktop environment.
one of the problems of Pd i see is, that all the audio backends are linked into the main binary. so if you have a binary with jack/dbus support, you *must* install jack/dbus or you will not be able to use Pd at all (even if you don't care for audio at all).
I'm thinking if we could build up a body of knowledge on this approach it would be the easiest way to get worry-free audio setups with GNU/Linux distros that wouldn't give new users headaches. Plus it would scale up: if they learn and care about insanely low latencies, they are already using JACK so it's just a matter of firing up qjackctl or whatever and configuring the audio server they've been using.
from a technical perspective, i think that the way to go is to support as many (pro and consumer) audio backends as possible, but always make this a runtime-choice (that is: make audio backend support in Pd a loadable mechanism)
fgamsdr IOhannes
________________________________ From: IOhannes m zmoelnig zmoelnig@iem.at To: pd-dev@iem.at Sent: Tuesday, May 28, 2013 3:26 AM Subject: Re: [PD-dev] jack dbus?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-05-28 07:08, Jonathan Wilkes wrote:
Ok, quick restatement of the problem:
How does one get Pd to just run in GNU/Linux for casual/sporadic use cases? Like 1 fire up Pd to patch an idea with Firefox/music player/other stuff sitting in the background 2 audio from online tutorial while patching in Pd with audio 3 some dude screwing around in Ubuntu with it, learns enough to get interested in fairly low latency to process some guitar sounds, possibly live
Cases 1 and 2 could benefit from having a PulseAudio backend in Pd, but case 3 would still be a pain because at the point that the guitarist cares about latency he/she is back to screwing around with audio settings (either directly through ALSA or with JACK). (If I'm wrong and Pulse can cover use case 3 I'd like to hear about it, but from what I've read Pulse is not designed with realtime audio processing as a goal.)
what works for me so far is:
- run jack as the native backend on my desktop (jackd gets autostarted
at login, and is running throughout my session)
How do you configure jack to start at login?
- -- obviously Pd will always use the jack backend
- run pulseaudio *on top of jack*.
Yes, that is the way to go. And as far as I can tell, that's what PulseAudio is supposed to do when jack is started, whether it's by jack d-bus, at login, or manually starting jack.
- -- thus any pulseaudio-aware application (like firefox) can simply
play back
- -- i can route pulseaudio-apps into Pd (not that i ever needed this
"in real life")
i really think that this is the way to go: have any consumer-framework sit on top of a "pro" framework, rather than the other way around (e.g. have pulseaudio provide a virtual alsa-device)
setting up was pretty easy by installing the "pulseaudio-module-jack" (on debian),and uninstalling all the other pa backends.
Why is it necessary to uninstall those other backends?
So, I'm curious about this: http://trac.jackaudio.org/wiki/JackDbusPackaging
Specifically the "D-bus only JACK" route. _If_ it works reliably (and of course that's a big if) then it gives the best of both worlds: all cases 1,2, and 3 above are covered by the JACK server automatically starting and Pulse getting out of the way for it. Moreover, Pulse clients get routed to JACK with what I take are "sane" defaults. So, if you have Pd running through JACK with this setup and then you open up a youtube video in Firefox, Pulse will automagically make a connection to JACK for it and (I'm guessing) hook it up to the output.
Any thoughts on this?
personally i would prefer to *not* pull in additional dependencies if possible. afair, d-bus is notorious for pulling in an entire desktop environment.
it does not depend on an entire desktop environment.
one of the problems of Pd i see is, that all the audio backends are linked into the main binary. so if you have a binary with jack/dbus support, you *must* install jack/dbus or you will not be able to use Pd at all (even if you don't care for audio at all).
I must be reading different documentation than you because AFAICT jack d-bus is a user-facing option for how to get JACK to interact with the system. Recommending it as the preferred way to connect doesn't require any backend coding.
But I'm not actually recommending it as the preferred way-- I still need to test it and compare it to the "classic" way of using JACK.
I'm thinking if we could build up a body of knowledge on this approach it would be the easiest way to get worry-free audio setups with GNU/Linux distros that wouldn't give new users headaches. Plus it would scale up: if they learn and care about insanely low latencies, they are already using JACK so it's just a matter of firing up qjackctl or whatever and configuring the audio server they've been using.
from a technical perspective, i think that the way to go is to support as many (pro and consumer) audio backends as possible, but always make this a runtime-choice (that is: make audio backend support in Pd a loadable mechanism)
That's a fine goal, as it would solve the problem about requiring JACK/ALSA dependencies even if the user doesn't want audio. But given a limited amount of time and money, the question is what is the easiest way to help new and old users avoid Linux Audio Hell? And I imagine that is currently either autostarting JACK at login or taking the JACK dbus route.
-Jonathan
fgamsdr IOhannes
_______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-05-29 06:12, Jonathan Wilkes wrote:
what works for me so far is: - - run jack as the native backend on my desktop (jackd gets autostarted at login, and is running throughout my session)
How do you configure jack to start at login?
i configre my desktop (xfce) to start "qjackctl" at startup, and configure qjackctl to start jackd at startup.
setting up was pretty easy by installing the "pulseaudio-module-jack" (on debian),and uninstalling all the other pa backends.
Why is it necessary to uninstall those other backends?
probably not necessary but mainly a precaution to not accidentally run a backend i don't want to use.
personally i would prefer to *not* pull in additional dependencies if possible. afair, d-bus is notorious for pulling in an entire desktop environment.
it does not depend on an entire desktop environment.
i dimly remember some discussion (on LAD, iirc) why having jack with d-bus enabled by default was a bad idea. maybe things have improved since then.
one of the problems of Pd i see is, that all the audio backends are linked into the main binary. so if you have a binary with jack/dbus support, you *must* install jack/dbus or you will not be able to use Pd at all (even if you don't care for audio at all).
I must be reading different documentation than you because AFAICT jack d-bus is a user-facing option for how to get JACK to interact with the system. Recommending it as the preferred way to connect doesn't require any backend coding.
maybe it's not clear from what i've written so far: i personally do not use jack/d-bus (or i am not aware of it). i was under the impression that it would require some linking against a different libjack, but it seems like that is all wrong.
obviously i have absolutely no problems against *recommending* a given setup that works with the given Pd-binaries.
sorry if i gave the wron impression
That's a fine goal, as it would solve the problem about requiring JACK/ALSA dependencies even if the user doesn't want audio. But given a limited amount of time and money,
well i have done a prototype of said plugable audio (and midi) backend support for Pd-0.43, and it's available on github.
code was only tested on linux and some users reported problems with the portaudio backend (which i had problems to reproduce, since i never use the portaudio backend (as it comes with Pd-vanilla) since i cannot remember that it ever worked for me...but then i didn't try that often after initial disappointments, being quite happy with what alsa and jack had to offer directly)
fgnsdart# IOhannes
On Wed, May 29, 2013, at 09:17 AM, IOhannes m zmoelnig wrote:
i dimly remember some discussion (on LAD, iirc) why having jack with d-bus enabled by default was a bad idea. maybe things have improved since then.
one of the problems of Pd i see is, that all the audio backends are linked into the main binary. so if you have a binary with jack/dbus support, you *must* install jack/dbus or you will not be able to use Pd at all (even if you don't care for audio at all).
I think the situation with jack is somewhat problematic, since there are now three variants of jack, where jack1 and jack2 both can be run as jackd - but jack1 and jack2 do not support the same stuff, and where jackdbus, while a form of jack2 is not operated the way jackd is. Perhaps it is a sign of an organizational problem within the jack community? I would really make things easier if there was only one jack.
From pd point of view, I suppose one could argue there is only two forms
of jack: jackd and jackdbus - would that be correct? Where jackd could be either jack1 or jack2.
This is something I'm beginning to see as somewhat of a problem in the Linux audio community, and as the project lead of Ubuntu Studio, I'm putting it as one my goals this year to see how we who package the applications can influence the infrastructure of the audio systems for the various Linux distros - in this case Debian and its derivatives. And also how we can influence the upstream jack developers as well.
Not sure if pulseaudio can be used for low latency. Haven't ever heard of anyone trying, but it is the standard sound system on most Linux distros today. Supporting it seems like a good idea. Even if you might not be able to get low latency.
Since I'm not much of a coder yet, I don't know very much about how applications interact with jack. But, from a user point of view, I'd prefer pd to autostart whatever jack is installed, preferably jackdbus over jackd, for the simple reason that it offers more functionality.
= About pulseaudio and jack integration (for those who are interested)
pulseaudio and jack integration is getting much better. With the release of pulseaudio 3.0 a bug was fixed, allowing jack to seemlessly grab a pulseaudio reserved card. (This works for jack2 only - which as said exists in two forms: jackd and jackdbus)
If having installed the jackdbus detect module (which is a part of pulseaudio source, but packaged separately), and you are running jackdbus, the module automatically creates a jack sink and source for pulseaudio, allowing the user to connect pulseaudio to jack.
So, if pd is set to start jackdbus by default, it would either just cut audio from pulseaudio completely (if pulse is using the same card), or with the module - more or less seemlessly connect pulseaudio to jack, keeping desktop audio intact.
There are still some problems with the module.
It eats a lot of CPU.
One problem is channel configuration. It's configurable nowadays, and I was able to make it default to 2 channels by default in the upstream source, which makes it go easier on the CPU, and makes it easier to use with multichannel cards (where the channel config might otherwise not make sense). It's missing the feature of profiles that audio cards otherwise have - stereo, 5.1, 7.1, etc.
Another problem, which is more about convenience, is that it doesn't automatically set applications that are already streaming audio to use the jack sink and source. You need to do that manually using a pulseaudio mixer.
I would say integrating pulseaudio and jack is working fairly well, but because you are dealing with two different audio systems, or three (if including alsa), as well as there being variants of jack, it is not easy to get an overview from the user point of view. There is no gui app that controls all of them.
= My recommendation
My recommendation at this point would be to let pd use pulseaudio by default (once it was supporting it). And if the user would set pd to use jack, it should start jackdbus if exists. And if not, jackd.
In the Ubuntu Studio team, we're talking about creating a gui application for controlling jack and the integration with pulseaudio in a much less painful way. Currently, the gui controls that exist don't really do that. I believe that would help smoothen some things out a bit.
________________________________ From: Kaj Ailomaa zequence@mousike.me To: pd-dev@iem.at Sent: Wednesday, May 29, 2013 4:29 AM Subject: Re: [PD-dev] jack dbus?
On Wed, May 29, 2013, at 09:17 AM, IOhannes m zmoelnig wrote:
i dimly remember some discussion (on LAD, iirc) why having jack with d-bus enabled by default was a bad idea. maybe things have improved since then.
one of the problems of Pd i see is, that all the audio backends are linked into the main binary. so if you have a binary with jack/dbus support, you *must* install jack/dbus or you will not be able to use Pd at all (even if you don't care for audio at all).
I think the situation with jack is somewhat problematic, since there are now three variants of jack, where jack1 and jack2 both can be run as jackd - but jack1 and jack2 do not support the same stuff, and where jackdbus, while a form of jack2 is not operated the way jackd is. Perhaps it is a sign of an organizational problem within the jack community? I would really make things easier if there was only one jack. From pd point of view, I suppose one could argue there is only two forms of jack: jackd and jackdbus - would that be correct? Where jackd could be either jack1 or jack2.
It makes no difference wrt development of Pd audio/midi backend for JACK because the same backend can connect to JACK no matter which of the above implementations is being used.
Thanks for the rest of what you wrote-- I will play with jackdbus a bit here on Wheezy when I get a chance.
-Jonathan
________________________________ From: IOhannes m zmoelnig zmoelnig@iem.at To: pd-dev@iem.at Sent: Wednesday, May 29, 2013 3:17 AM Subject: Re: [PD-dev] jack dbus?
[...]
personally i would prefer to *not* pull in additional dependencies if possible. afair, d-bus is notorious for pulling in an entire desktop environment.
it does not depend on an entire desktop environment.
i dimly remember some discussion (on LAD, iirc) why having jack with d-bus enabled by default was a bad idea. maybe things have improved since then.
Probably.
one of the problems of Pd i see is, that all the audio backends are linked into the main binary. so if you have a binary with jack/dbus support, you *must* install jack/dbus or you will not be able to use Pd at all (even if you don't care for audio at all).
I must be reading different documentation than you because AFAICT jack d-bus is a user-facing option for how to get JACK to interact with the system. Recommending it as the preferred way to connect doesn't require any backend coding.
maybe it's not clear from what i've written so far: i personally do not use jack/d-bus (or i am not aware of it). i was under the impression that it would require some linking against a different libjack, but it seems like that is all wrong.
obviously i have absolutely no problems against *recommending* a given setup that works with the given Pd-binaries.
sorry if i gave the wron impression
That's a fine goal, as it would solve the problem about requiring JACK/ALSA dependencies even if the user doesn't want audio. But given a limited amount of time and money,
well i have done a prototype of said plugable audio (and midi) backend support for Pd-0.43, and it's available on github.
code was only tested on linux and some users reported problems with the portaudio backend (which i had problems to reproduce, since i never use the portaudio backend (as it comes with Pd-vanilla) since i cannot remember that it ever worked for me...but then i didn't try that often after initial disappointments, being quite happy with what alsa and jack had to offer directly)
Ok, sounds like you have two things: a) code that adds support for pluggable audio/midi backends, and b) a pluggable portaudio backend.
Does the backend have to be written differently than the s_audio_*.c stuff to be pluggable?
-Jonathan
fgnsdart# IOhannes
_______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-05-29 17:21, Jonathan Wilkes wrote:
Ok, sounds like you have two things: a) code that adds support for pluggable audio/midi backends, and b) a pluggable portaudio backend.
i have two things: - - code (API+ implementation) that adds support for pluggable audio/midi backends - - converted all the existing backends to use the new API (though they are still linked statically into the Pd-binary)
the code was only updated to Pd-0.43, and i haven't updated it to Pd-0.44.
Does the backend have to be written differently than the s_audio_*.c stuff to be pluggable?
not really . the idea was to have an API that builds on top of the current implementation of s_audio_... (which is pretty consistent throughout the various backends)
so it's mainly adding a few wrapper functions that register a given backend to the core.
you can have a look at it at [1]
fgamsdr IOhannes
[1] https://github.com/umlaeute/pd-vanilla/tree/mediabackends
________________________________ From: IOhannes m zmoelnig zmoelnig@iem.at To: pd-dev@iem.at Sent: Wednesday, May 29, 2013 11:32 AM Subject: Re: [PD-dev] jack dbus?
[...]
i have two things:
- code (API+ implementation) that adds support for pluggable
audio/midi backends
- converted all the existing backends to use the new API (though they
are still linked statically into the Pd-binary)
What did you have to convert?
Also-- you mentioned people had tested Portaudio as pluggable backend. Have you tested using a known configuration (like with the ALSA backend) with your changes?
the code was only updated to Pd-0.43, and i haven't updated it to Pd-0.44.
Does the backend have to be written differently than the s_audio_*.c stuff to be pluggable?
not really
.
the idea was to have an API that builds on top of the current implementation of s_audio_... (which is pretty consistent throughout the various backends)
so it's mainly adding a few wrapper functions that register a given backend to the core.
you can have a look at it at [1]
Thanks, I'll check it out.
-Jonathan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-05-29 17:49, Jonathan Wilkes wrote:
- converted all the existing backends to use the new API
(though they are still linked statically into the Pd-binary)
What did you have to convert?
check the git logs. (or read my answer on "does the backend have to be written differently?")
Also-- you mentioned people had tested Portaudio as pluggable backend. Have you tested using a known configuration (like with the ALSA backend) with your changes?
sigh. yes, i usually do test my code. ALSA and jack seemed to work *as good* as the original (built-in) version.
fgmasdr IOhannes
On Mon, 2013-05-27 at 22:08 -0700, Jonathan Wilkes wrote:
Ok, quick restatement of the problem:
How does one get Pd to just run in GNU/Linux for casual/sporadic use cases? Like 1 fire up Pd to patch an idea with Firefox/music player/other stuff sitting in the background 2 audio from online tutorial while patching in Pd with audio 3 some dude screwing around in Ubuntu with it, learns enough to get interested in fairly low latency to process some guitar sounds, possibly live
Cases 1 and 2 could benefit from having a PulseAudio backend in Pd, but case 3 would still be a pain because at the point that the guitarist cares about latency he/she is back to screwing around with audio settings (either directly through ALSA or with JACK). (If I'm wrong and Pulse can cover use case 3 I'd like to hear about it, but from what I've read Pulse is not designed with realtime audio processing as a goal.)
So, I'm curious about this: http://trac.jackaudio.org/wiki/JackDbusPackaging
Specifically the "D-bus only JACK" route. _If_ it works reliably (and of course that's a big if) then it gives the best of both worlds: all cases 1,2, and 3 above are covered by the JACK server automatically starting and Pulse getting out of the way for it. Moreover, Pulse clients get routed to JACK with what I take are "sane" defaults. So, if you have Pd running through JACK with this setup and then you open up a youtube video in Firefox, Pulse will automagically make a connection to JACK for it and (I'm guessing) hook it up to the output.
Any thoughts on this?
I think I'm with IOhannes here. I feel pulseaudio and JACK come with separate promises. Besides providing quite a lot of solutions to many problems, pulseaudio's major goal is its ease of use, i.e. you don't necessarily need to be aware you're using it. JACK is about latency and connecting audio software and people who use it most likely know why they are using it. I think you can only optimize latency by manually trying to find the optimal parameters to JACK. Having too much "auto-magic" might be detrimental to what people expect it to do.
Personally, I'd appreciate if Pd would support pulseaudio. If Pd covers many backends, it is easy for package maintainers to package Pd with default suitable for the specific distro. In my opinion, it would be sane to let Pd default to pulseaudio in Ubuntu. In pure:dyne JACK would probably make more sense.
Actually, using JACK is already quite easy today, even in the pulseaudio using distros. When I start JACK from qjackctl, pulseaudio is immediately stopped and frees the device. So I don't see much room for improvement there.
Routing pulseaudio to JACK is already quite easy, but I wouldn't want it to happen automatically. Imagine during a performance I'd accidentally click on a link and Firefox would start to play some Youtube movie on my x channel setup. Another a smallish issue I experienced with pulse->Jack is that the volume keys of my laptop only control the master volume of pulse and thus do not control the actual device anymore.
Roman
________________________________ From: Roman Haefeli reduzent@gmail.com To: pd-dev@iem.at Sent: Tuesday, May 28, 2013 5:53 AM Subject: Re: [PD-dev] jack dbus?
[...]
Personally, I'd appreciate if Pd would support pulseaudio. If Pd covers many backends, it is easy for package maintainers to package Pd with default suitable for the specific distro. In my opinion, it would be sane to let Pd default to pulseaudio in Ubuntu.
Curious here how low the latency could get before dropouts.
Actually, using JACK is already quite easy today, even in the pulseaudio
using distros. When I start JACK from qjackctl, pulseaudio is immediately stopped and frees the device. So I don't see much room for improvement there.
You have to manually start another program before opening the program you want to use.
Routing pulseaudio to JACK is already quite easy, but I wouldn't want it
to happen automatically. Imagine during a performance I'd accidentally click on a link and Firefox would start to play some Youtube movie on my x channel setup.
With qjackctl you could just uncheck the "Use dbus" checkbutton and/or load a patchbay setting specifically for the performance. I don't think there's anything wrong with taking steps to prepare a system for a performance-- I'd just like to have as few steps as possible for getting (quality) sound in all kinds of multitasking situations.
-Jonathan
Another a smallish issue I experienced with pulse->Jack
is that the volume keys of my laptop only control the master volume of pulse and thus do not control the actual device anymore.
Roman
_______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Tue, May 28, 2013 at 7:08 AM, Jonathan Wilkes jancsika@yahoo.com wrote: [...]
So, I'm curious about this: http://trac.jackaudio.org/wiki/JackDbusPackaging
Specifically the "D-bus only JACK" route. _If_ it works reliably (and of course that's a big if) then it gives the best of both worlds: all cases 1,2, and 3 above are covered by the JACK server automatically starting and Pulse getting out of the way for it. Moreover, Pulse clients get routed to JACK with what I take are "sane" defaults. So, if you have Pd running through JACK with this setup and then you open up a youtube video in Firefox, Pulse will automagically make a connection to JACK for it and (I'm guessing) hook it up to the output.
Any thoughts on this? I'm thinking if we could build up a body of knowledge on this approach it would be the easiest way to get worry-free audio setups with GNU/Linux distros that wouldn't give new users headaches. Plus it would scale up: if they learn and care about insanely low latencies, they are already using JACK so it's just a matter of firing up qjackctl or whatever and configuring the audio server they've been using.
Anyway I'll do some testing with it on Debian Wheezy over the next month. If anyone wants to try on other distros that'd be helpful (Linux Mint, Ubuntu, etc.)
I checked it on Xubuntu: running Pulseaudio as an audio submixer through JACK . In Pulseaudio's mixer GUI (which is the default mixer in Xubuntu's panel), JACK can be selected as destination for an application's audio output, but only when the application is indeed delivering audio. For example, when a video is playing in Firefox, the audio interface option boxes appear.
Setting up the connections manually is time-consuming. But, since JACK adds some latency to Pd, I would not use it as default (autostart) setup. The lowest practical roundtrip latency through Pd I could get in the JACK-with-Pulseaudio setup was measured 50 ms, 32 ms more than directly through ALSA.
Is there not another way to play sound files or tutorial video's together with Pd? I found one nice alternative: make VLC JACK-aware and use it to play media files and network streams through JACK. To prepare the setup:
- install vlc package (multimedia player and streamer) if it's not already installed - install vlc-plugin-jack package - in VLC preferences, set audio output to JACK
A Youtube video can be played in VLC via menu Media >> Open Network Stream. It should be possible for other streams as well but I still have to find out how to do Vimeo or Soundcloud. The VLC/JACK route would not be most convenient to watch internet video clips on a regular basis. However for incidental use, the advantage is that VLC connection is quickly made in JACK.
Katja
Best, Jonathan
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________ From: katja katjavetter@gmail.com To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-dev@iem.at" pd-dev@iem.at Sent: Wednesday, May 29, 2013 8:21 AM Subject: Re: [PD-dev] jack dbus?
I checked it on Xubuntu: running Pulseaudio as an audio submixer through JACK . In Pulseaudio's mixer GUI (which is the default mixer in Xubuntu's panel), JACK can be selected as destination for an application's audio output, but only when the application is indeed delivering audio. For example, when a video is playing in Firefox, the audio interface option boxes appear.
So when you pause the video does the option box go away?
Setting up the connections manually is time-consuming. But, since JACK adds some latency to Pd, I would not use it as default (autostart) setup. The lowest practical roundtrip latency through Pd I could get in the JACK-with-Pulseaudio setup was measured 50 ms, 32 ms more than directly through ALSA.
Hm... http://jackaudio.org/no_extra_latency
I'm talking about running PulseAudio on top of JACK and not the other way around. Is that what you're doing?
Is there not another way to play sound files or tutorial video's together with Pd? I found one nice alternative: make VLC JACK-aware and use it to play media files and network streams through JACK. To prepare the setup:
- install vlc package (multimedia player and streamer) if it's not
already installed
- install vlc-plugin-jack package
- in VLC preferences, set audio output to JACK
A Youtube video can be played in VLC via menu Media >> Open Network Stream. It should be possible for other streams as well but I still have to find out how to do Vimeo or Soundcloud. The VLC/JACK route would not be most convenient to watch internet video clips on a regular basis. However for incidental use, the advantage is that VLC connection is quickly made in JACK.
I''ve done that before to port youtube audio into Pd. While it's certainly handy it's a lot of work just to get a GNU/Linux machine to behave with one other general audio use-case.
-Jonathan
On Wed, May 29, 2013, at 05:00 PM, Jonathan Wilkes wrote:
From: katja katjavetter@gmail.com To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-dev@iem.at" pd-dev@iem.at Sent: Wednesday, May 29, 2013 8:21 AM Subject: Re: [PD-dev] jack dbus?
I checked it on Xubuntu: running Pulseaudio as an audio submixer through JACK . In Pulseaudio's mixer GUI (which is the default mixer in Xubuntu's panel), JACK can be selected as destination for an application's audio output, but only when the application is indeed delivering audio. For example, when a video is playing in Firefox, the audio interface option boxes appear.
The pulseaudio mixer allows you to set sink per application. This is under the "playback" tab, which only shows currently streaming applications. You can also select jack as the default output under the tab "output devices", in which case all applications will use jack by default. It's the button that when hovering over it says "Set as fallback".
What you need to install in order for this to work automatically: jackd2 (and start jackdbus, not jackd) pulseaudio-module-jack (the jackdbus_detect module)
It is possible to have PA create or destroy sink and source for jack manually as well, using the pactl tool. This will also work for jackd (jack2 only).
On Wed, May 29, 2013 at 5:00 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
I checked it on Xubuntu: running Pulseaudio as an audio submixer through JACK . In Pulseaudio's mixer GUI (which is the default mixer in Xubuntu's panel), JACK can be selected as destination for an application's audio output, but only when the application is indeed delivering audio. For example, when a video is playing in Firefox, the audio interface option boxes appear.
So when you pause the video does the option box go away?
The controls for Firefox disappear when Firefox is closed, but also when going to an URL without media stream.
It seems that the quickest way to make it work is: first make sure that pulsaudio does not run (and is not autospawned), then start jackdbus via QjackCtl, then start pulseaudio. This way, pulsaudio sink and source are automatically connected in JACK, and JACK is automatically selected as the sink for Firefox in Pulseaudio's mixer (I don't get an option box any more).
Setting up the connections manually is time-consuming. But, since JACK adds some latency to Pd, I would not use it as default (autostart) setup. The lowest practical roundtrip latency through Pd I could get in the JACK-with-Pulseaudio setup was measured 50 ms, 32 ms more than directly through ALSA.
Hm... http://jackaudio.org/no_extra_latency
I'm talking about running PulseAudio on top of JACK and not the other way around. Is that what you're doing?
I know only one way at the moment: routing Pulseaudio through JACK, equivalent to how Pd is routed through JACK. If this is called 'Pulseaudio on top of JACK', then 'yes'. The extra latency is because I need to set 2 periods of 512 samples (23 ms) for JACK's buffering to get audio without dropouts in this setup. In Pd I have it fixed at 15 ms. In practice there are more causes for latency, so I measure roundtrip latency in Pd with a sample-precise routine (see attached patch 'latency-tester2.pd'). Pd's 15 nominal ms is in practice 18 ms when routed directly via ALSA. Via the JACK + Pulseaudio setup it is a total of 50 ms in practice.
By the way this does of course not say anything about latency in Pulseaudio. Maybe there is a way to test that with a 'pulsified' application, for example Audacity.
Katja
________________________________ From: katja katjavetter@gmail.com To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-dev@iem.at" pd-dev@iem.at Sent: Wednesday, May 29, 2013 1:12 PM Subject: Re: [PD-dev] jack dbus?
[...]
I know only one way at the moment: routing Pulseaudio through JACK, equivalent to how Pd is routed through JACK. If this is called 'Pulseaudio on top of JACK', then 'yes'. The extra latency is because I need to set 2 periods of 512 samples (23 ms) for JACK's buffering to get audio without dropouts in this setup. In Pd I have it fixed at 15 ms. In practice there are more causes for latency, so I measure roundtrip latency in Pd with a sample-precise routine (see attached patch 'latency-tester2.pd'). Pd's 15 nominal ms is in practice 18 ms when routed directly via ALSA. Via the JACK + Pulseaudio setup it is a total of 50 ms in practice.
There's no other combination of frames/period and period/buffer you can use to get ca. 17-20ms latency without dropouts?
By the way this does of course not say anything about latency in Pulseaudio. Maybe there is a way to test that with a 'pulsified' application, for example Audacity.
That would be interesting to see.
-Jonathan
On Wed, May 29, 2013 at 7:32 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
There's no other combination of frames/period and period/buffer you can use to get ca. 17-20ms latency without dropouts?
Not on the hardware I'm using. I guess the absolute latency could be lower on faster hardware, but my point was to compare the different routings while keeping other conditions equal.
By the way this does of course not say anything about latency in Pulseaudio. Maybe there is a way to test that with a 'pulsified' application, for example Audacity.
That would be interesting to see.
By way of test, in Audacity I've set recording and playback device to pulse, and recorded a click at time zero from track 1 to track 2 via loopback. Buffer size and latency compensation were both set to 100 ms so they should compensate each other. The recorded impulse appears at around 0.058 seconds. If I've done it right, this would point to 58 ms total roundtrip latency. In a real time application like Pd you could not compensate for latency, so Pd's own buffer length should probably be added to the figure, making some 70 ms as a minimum.
It seems to me that direct PulseAudio support for Pd would be interesting for ease of use, especially important for Pd/Linux beginners. Long latency is annoying, but at least less confusing than having no audio at all from some applications. However, it should be noted that Pulseaudio's mixer does not by definition provide controls for all (parts of) hardware devices. In some cases, it silently switches an input or output, without presenting the corresponding button on the mixer GUI. In such a case, only an ALSA mixer gives control over the hardware, and pulseaudio must be killed to return control to the ALSA mixer. So, Pulseaudio can make things very confusing too. But that goes beyond the influence of Pd.
Katja
________________________________ From: katja katjavetter@gmail.com To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-dev@iem.at" pd-dev@iem.at Sent: Wednesday, May 29, 2013 4:00 PM Subject: Re: [PD-dev] jack dbus?
On Wed, May 29, 2013 at 7:32 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
There's no other combination of frames/period and period/buffer you can use to get ca. 17-20ms latency without dropouts?
Not on the hardware I'm using.
Any ideas on what is causing the discrepancy? It has to be either a bug in JACK/Pd/OS, or some configuration detail (e.g., JACK isn't in realtime mode or something more subtle). I wouldn't think it has to do with your specific audio device as JACK uses ALSA as a backend.
I have a hard time believing every Ardour user/dev would be putting up with a latency that high when simply going straight through ALSA would be that much better.
By the way this does of course not say anything about latency in Pulseaudio. Maybe there is a way to test that with a 'pulsified' application, for example Audacity.
That would be interesting to see.
By way of test, in Audacity I've set recording and playback device to pulse, and recorded a click at time zero from track 1 to track 2 via loopback. Buffer size and latency compensation were both set to 100 ms so they should compensate each other. The recorded impulse appears at around 0.058 seconds. If I've done it right, this would point to 58 ms total roundtrip latency. In a real time application like Pd you could not compensate for latency, so Pd's own buffer length should probably be added to the figure, making some 70 ms as a minimum.
If your numbers are right, then that would be large enough to disqualify use-case #3 that I gave: guy screwing around with guitar processing, possibly live. The latency is too high for that.
I think this is the case for the default setting on Windows. At least the last time I did audio on Windows the default latency in Pd's setting was something like 100ms. It means that if/when the user hits upon a patch where lower latency matters there is a whole host of issues they must confront.
So I suppose if a large portion of (GNU/Linux) Pd users don't need to get low latency at all, then it's beneficial to have a default audio backend that works like everything else in their distro. However, if getting low latency is a common goal then it's very important to lay out some instructions for how best to set up JACK to get reliable low-latency performance.
Of course both can be done at the same time if there's enough interest. (Personally, I want to give the latter priority since it's way harder to get reliable low-latency setup than it is to get Pd to produce sound in the first place.)
It seems to me that direct PulseAudio support for Pd would be interesting for ease of use, especially important for Pd/Linux beginners. Long latency is annoying, but at least less confusing than having no audio at all from some applications. However, it should be noted that Pulseaudio's mixer does not by definition provide controls for all (parts of) hardware devices. In some cases, it silently switches an input or output, without presenting the corresponding button on the mixer GUI. In such a case, only an ALSA mixer gives control over the hardware, and pulseaudio must be killed to return control to the ALSA mixer. So, Pulseaudio can make things very confusing too. But that goes beyond the influence of Pd.
Actually, I _think_ Pd's ALSA backend and interface complicates things another way. The user is presented with a series of device names after they choose the ALSA api, but Pd-gui forwards device numbers to Pd, as well as saving device numbers in the preferences file. If you choose that usb microphone that you just plugged in by name in the dropdown list and save your preferences, you're not guaranteed to get it back the next time you run Pd because the device number might be assigned to something else. (Simple example: you're using a usb audio interface and a usb microphone.)
It's tangential to the issue you describe, but in both cases Hal isn't opening the pod bay door. :)
-Jonathan
On Wed, May 29, 2013 at 7:32 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
There's no other combination of frames/period and period/buffer you can use to get ca. 17-20ms latency without dropouts?
Not on the hardware I'm using.
Any ideas on what is causing the discrepancy? It has to be either a bug in JACK/Pd/OS, or some configuration detail (e.g., JACK isn't in realtime mode or something more subtle). I wouldn't think it has to do with your specific audio device as JACK uses ALSA as a backend.
I have a hard time believing every Ardour user/dev would be putting up with a latency that high when simply going straight through ALSA would be that much better.
Note that the buffer settings I mentioned were for the routing under discussion: Pd and Pulseaudio through JACK, and playing a Youtube video together with Pd audio. This is more demanding than just Pd, so I'm not surprised that it can't be done with shorter JACK buffer. It's already shorter than QjackCtl's default (2*1024). I don't think there's something wrong with my audio setup (but the laptop specs are modest with 1 GHz core2duo, no preemptive kernel). Jackaudio.org's 'no-latency' statement to which you referred is weird. This article is more practical:
http://apps.linuxaudio.org/wiki/jack_latency_tests
I'm curious what measured roundtrip latency through Pd you can get on your system when playing an internet video simultaneously, Jonathan?
[...]
So I suppose if a large portion of (GNU/Linux) Pd users don't need to get low latency at all, then it's beneficial to have a default audio backend that works like everything else in their distro. However, if getting low latency is a common goal then it's very important to lay out some instructions for how best to set up JACK to get reliable low-latency performance.
Of course both can be done at the same time if there's enough interest. (Personally, I want to give the latter priority since it's way harder to get reliable low-latency setup than it is to get Pd to produce sound in the first place.)
Even if someone develops pulseaudio support for Pd today, it will take a while before it's in a release. Testing and documenting other mixing setups is a good idea anyway.
Katja
________________________________ From: katja katjavetter@gmail.com To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-dev@iem.at" pd-dev@iem.at Sent: Saturday, June 1, 2013 2:39 PM Subject: Re: [PD-dev] jack dbus?
On Wed, May 29, 2013 at 7:32 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
There's no other combination of frames/period and period/buffer you can use to get ca. 17-20ms latency without dropouts?
Not on the hardware I'm
using.
Any ideas on what is causing the discrepancy? It has to be either a bug in JACK/Pd/OS, or some configuration detail (e.g., JACK isn't in realtime mode or something more subtle). I wouldn't think it has to do with your specific audio device as JACK uses ALSA as a backend.
I have a hard time believing every Ardour user/dev would be putting up with a latency that high when simply going straight through ALSA would be that much better.
Note that the buffer settings I mentioned were for the routing under discussion: Pd and Pulseaudio through JACK, and playing a Youtube video together with Pd audio.
Ah, I see.
This is more demanding than just Pd, so I'm
not surprised that it can't be done with shorter JACK buffer. It's
already shorter than QjackCtl's default (2*1024). I don't think there's something wrong with my audio setup (but the laptop specs are modest with 1 GHz core2duo, no preemptive kernel). Jackaudio.org's 'no-latency' statement to which you referred is weird. This article is more practical:
I don't see any conflict between that and what the JACK site says.
For my own laptop, Pd->ALSA works without dropouts at 5ms and Pd->JACK (->ALSA) at 5.8ms. They are set differently: setting ALSA in Pd requires an integer, and JACK has power or two frames/period and integer periods/buffer. So unfortunately there's no way to set JACK to exactly 5ms for comparison (and setting very small frames/period with many periods/buffer creates a stream of xruns even with latency > 8ms). Of course these are just the latencies in the settings-- I haven't done the actual measurements yet.
Also the statement on the jack_latency_tests link you gave that says <10ms latency on GNU/Linux systems requires a real-time kernel requires clarification. If someone wants reliable <10ms latency and isn't getting it, the very first thing to do is make sure that _nothing_ unnecessary is running (or scheduled to run) on the machine. There may be no need to install another kernel if it's the stupid Gnome indexer junk whirring in the background that's causing xruns. Or one of the other 30+ programs that are part of a system that seems perfectly happy to take 10+ seconds to load the desktop environment after the user logs in. Without taking that into consideration (especially as desktop environments that ship with the popular distros get more and more complex) realtime kernel is useless.
Also in my own tests (only with a single laptop) the realtime kernel provides more predictable cpu usage. If a test patch averages 40% cpu, then under the rt kernel it may be +/- 1%, whereas without rt kernel it may be +/- 6%. But I'm not able to set much lower latency in JACK with rt-kernel than I am with stock kernel with rt priorities. Is this the experience of others?
I'm curious what measured roundtrip latency through Pd you can get on your system when playing an internet video simultaneously, Jonathan?
Unfortunately it will have to be using a vlc-jack backend for the internet video-- not Pulse, because PulseAudio+JACK is being screwy on my machine atm.
[...]
So I suppose if a large portion of (GNU/Linux) Pd users don't need to get low latency at all, then it's beneficial to have a default audio backend that works like everything else in
their distro. However, if
getting low latency is a common goal then it's very important to lay out some instructions for how best to set up JACK to get reliable low-latency performance.
I agree. And at least these numbers are nowhere near the despicable latencies on 10-foot user interfaces where the user may have to wait up to five seconds just to know that the batteries in the remote aren't dead.
But maybe Pd just needs to go in the other direction, so latency is at minimum a couple of weeks. Is the audio that you patched at the beginning of the month worth listening to at the end of it? Think of it as a self spam filter. :)
Of course both can be done at the same time if there's enough interest. (Personally, I want to give the latter priority since it's way harder to get reliable low-latency setup than it is to get Pd to produce sound in the first place.)
Even if someone develops pulseaudio support for Pd today, it will take a while before it's in a release. Testing and documenting other mixing setups is a good idea anyway.
I agree and will try those latency tests when I get a chance.
-Jonathan
Katja
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-06-02 08:51, Jonathan Wilkes wrote:
Of course these are just the latencies in the settings-- I haven't done the actual measurements yet.
it would be interesting to have actual measurements. everything else is wild speculation.
fgmadsr IOhannes
On Mon, Jun 3, 2013 at 9:04 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2013-06-02 08:51, Jonathan Wilkes wrote:
Of course these are just the latencies in the settings-- I haven't done the actual measurements yet.
it would be interesting to have actual measurements. everything else is wild speculation.
Right. I would propose the following measurement protocol:
(setup/usecase A: Pd only through ALSA) 1. In Pd using ALSA backend, run sine test signal in 'Media > Test Audio and Midi...' 2. Set Pd's buffer to lowest possible value such that there are no I/O error messages or audible dropouts during 'normal Pd use', that is, while clicking (radio)buttons or switching between already loaded Pd windows. 3. For this nominal latency setting, measure actual roundtrip latency via line loopback or speaker / mic loopback, using patch latency-tester2.pd which was attached to my May 29 post in this thread.
(setup/usecase B: Pd and PulseAudio through JACK/ALSA) 4. Set up a routing with Pd and PulseAudio as JACK clients. 5. In Pd, run the sine test signal. Simultaneously, play this video in a browser while routing it's sound through PulseAudio / JACK: http://www.youtube.com/watch?v=_63Cc6vPFVI&feature=youtu.be 6. For this combination, get the lowest nominal latency in Jack such that there are no I/O errors in Pd, or audible dropouts in either audio signal. JACK must be restarted for a new buffer setting to take effect. This is the most time-consuming aspect of the measurement. 7. For this routing and settings, measure the actual roundtrip latency through Pd.
8. Report nominal + measured latencies for setup A and B, together with relevant hardware and system info.
My results for Panasonic CF-19 1 GHz Core2Duo, Xubuntu 12.04, built-in soundcard, no preemptive kernel: - setup/usecase A: 15 ms buffer in Pd, 18 ms measured roundtrip latency - setup/usecase B: 15 ms buffer in Pd, 23.2 ms (2*512 samples) buffer in JACK, 49.3 ms measured rountrip latency through Pd
I would suggest we do Pd+PulseAudio-through-JACK discussion on pd-list if we continue this. The how-to and details of it are not a dev topic, though the consideration of writing direct PulseAudio support for Pd is.
Katja
________________________________ From: katja katjavetter@gmail.com To: IOhannes m zmoelnig zmoelnig@iem.at Cc: pddev pd-dev@iem.at Sent: Monday, June 3, 2013 7:09 AM Subject: Re: [PD-dev] jack dbus?
On Mon, Jun 3, 2013 at 9:04 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2013-06-02 08:51, Jonathan Wilkes
wrote:
Of course these are just the latencies in the settings-- I haven't done the actual measurements
yet.
it would be interesting to have actual measurements. everything else is wild speculation.
Right. I would propose the following measurement protocol:
(setup/usecase A: Pd only through ALSA)
- In Pd using ALSA backend, run sine test signal in 'Media > Test
Audio and Midi...' 2. Set Pd's buffer to lowest possible value such that there are no I/O error messages or audible dropouts during 'normal Pd use', that is, while clicking (radio)buttons or switching between already loaded Pd windows. 3. For this nominal latency setting, measure actual roundtrip latency via line loopback or speaker / mic loopback, using patch latency-tester2.pd which was attached to my May 29 post in this thread.
Ok, I just need a loopback cord.
(I tried using [r~ foo]---[s~ foo] but when I drag the containing patch to move it down toward my physical connectors on the laptop, it goes outside the screen area and I can't tell whether it's lined up correctly with them. I think the problem is that my screen only bends down 45 degrees, so the patch doesn't end up on the same plane as the physical inputs. Also the wire in Pd is too far to the left so I probably can't even shove the objects far enough into the cavity to get them to connect without breaking the connection.)
(setup/usecase B: Pd and PulseAudio through JACK/ALSA) 4. Set up a routing with Pd and PulseAudio as JACK clients. 5. In Pd, run the sine test signal. Simultaneously, play this video in a browser while routing it's sound through PulseAudio / JACK: http://www.youtube.com/watch?v=_63Cc6vPFVI&feature=youtu.be 6.
For this combination, get the lowest nominal latency in Jack such
that there are no I/O errors in Pd, or audible dropouts in either audio signal. JACK must be restarted for a new buffer setting to take effect. This is the most time-consuming aspect of the measurement. 7. For this routing and settings, measure the actual roundtrip latency through Pd.
In all serious now... :)
Don't we want to compare straight to ALSA to pd to JACK to ALSA, just with Pd running? Having Pulse in the mix is good to measure as well, but I'd like to get a handle on the "JACK adds no latency" statement and comparing additionally with just Pd running through JACK will simplify that.
Also, it may be helpful to add: Pd through JACK, VLC using JACK backend through Jack and compare it to the one using PulseAudio through JACK.
Another question: what are you using to play the Youtube video? I know the proprietary Flash plugin caused problems with Pulse at one point. Regardless, we should all be using the same plugin for the comparison. (Or maybe just the same network stream through VLC, one using JACK backend and the other using the Pulse one.)
My results for Panasonic CF-19 1 GHz Core2Duo, Xubuntu 12.04, built-in soundcard, no preemptive kernel:
- setup/usecase A: 15 ms buffer in Pd, 18 ms measured roundtrip latency
- setup/usecase B:
15 ms buffer in Pd, 23.2 ms (2*512 samples) buffer
in JACK, 49.3 ms measured rountrip latency through Pd
RFC: for the Pd preferences dialog, I think the "delay" entry box should be either disabled or replaced with a label that says "set with JACK" when the JACK api is chosen. On my system setting the delay from within Pd has no impact-- you can even set it to zero!
-Jonathan
On Mon, Jun 3, 2013 at 9:25 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
[...]
Don't we want to compare straight to ALSA to pd to JACK to ALSA, just with Pd running? Having Pulse in the mix is good to measure as well, but I'd like to get a handle on the "JACK adds no latency" statement and comparing additionally with just Pd running through JACK will simplify that.
Also, it may be helpful to add: Pd through JACK, VLC using JACK backend through Jack and compare it to the one using PulseAudio through JACK.
If I'm not mistaken, it was your original idea to test a setup where all audio sources can be played together with Pd, i.e. Pd + PulseAudio + JACK, and compare with Pd's current default routing (plain ALSA). So that's what I did. I'm now eager to know results from others before further delving into it.
Another question: what are you using to play the Youtube video? I know the proprietary Flash plugin caused problems with Pulse at one point.
Flash plugin indeed (no problem with Pulse on Xubuntu). Should we better find an HTML5 stream for the test?
[...]
Katja
________________________________ From: katja katjavetter@gmail.com To: Jonathan Wilkes jancsika@yahoo.com Cc: IOhannes m zmoelnig zmoelnig@iem.at; pddev pd-dev@iem.at Sent: Monday, June 3, 2013 6:23 PM Subject: Re: [PD-dev] jack dbus?
On Mon, Jun 3, 2013 at 9:25 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
[...]
Don't we want to compare straight to ALSA to pd to JACK to ALSA, just with Pd running? Having Pulse in the mix is good to measure as well, but I'd like to get a handle on the "JACK adds no latency" statement and comparing additionally with just Pd running through JACK will simplify that.
Also, it may be helpful to add: Pd through JACK, VLC using JACK backend through Jack and compare it to the one using PulseAudio through JACK.
If I'm not mistaken, it was your original idea
to test a setup where
all audio sources can be played together with Pd, i.e. Pd + PulseAudio
- JACK, and compare with Pd's current default routing (plain ALSA). So
that's what I did. I'm now eager to know results from others before further delving into it.
Sorry, I'm talking about a few things at once. One would be to test Pd by itself with ALSA backend vs. Pd by itself with JACK backend. That would provide some data re: the page you linked to about latency. (My suggestion about Pd->JACK + VLC-with-jack-backend->JACK was meant to cover that case and also compare to Pd->JACK +Pulse->JACK, but as you say we can delve into that later.)
The other is: what's a "recommendable" setup for using Pd in GNU/Linux with acceptable/controllable latency while still behaving with the rest of the system. Your Pd/Pulse/JACK measurements help to address that.
So [when I find my cord] I'll give results for: Pd by itself directly to ALSA Pd by itself through JACK (with qjackctl, and with ALSA as JACK's backend) Pd to JACK + "other stuff" through Pulse to JACK
Another question: what are you using to play the Youtube video? I know the proprietary Flash plugin caused problems with Pulse at one point.
Flash plugin indeed (no problem with Pulse on Xubuntu). Should we better find an HTML5 stream for the test?
Sure, if you have a link then that would be preferable-- I think HTML5 should have better coverage than proprietary Flash (at least Debian doesn't ship with it, which I like). Or if you have VLC, opening a stream there-- it has a Pulse backend as well as a JACK one so it'd be easy to test with both. (But if you don't then HTML5 is best.)
-Jonathan
[...]
Katja
On Tue, Jun 4, 2013 at 3:08 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
[...]
Sorry, I'm talking about a few things at once. One would be to test Pd by itself with ALSA backend vs. Pd by itself with JACK backend. That would provide some data re: the page you linked to about latency. (My suggestion about Pd->JACK + VLC-with-jack-backend->JACK was meant to cover that case and also compare to Pd->JACK +Pulse->JACK, but as you say we can delve into that later.)
The other is: what's a "recommendable" setup for using Pd in GNU/Linux with acceptable/controllable latency while still behaving with the rest of the system. Your Pd/Pulse/JACK measurements help to address that.
You're right, JACK's latency 'discrepancy' should be investigated separately. On my system I observe this behaviour:
- Pd with ALSA: measured latency is [Pd-nominal-latency + 3] milliseconds - Pd through JACK with ALSA: measured latency is [JACK-nominal-latency * 2 + 3] ms - Pd + PulseAudio through JACK with ALSA: [JACK-nominal-latency * 2 + 3] ms
Here it seems that JACK's latency is double it's buffer size, no matter if PulseAudio is connected or not. But wait, it's logical! The loopback signal goes through JACK twice. Buffering is applied at capture and at playback, and by default both buffers have size [frames * periods]. Check with command jack_lsp -l. Optionally, extra input and/or output latency can be added, however this does not reflect in my measurements.
Apart from the effect that JACK's latency may be different from what you'd expect, there is the effect that Pd + internet video requires more buffering than Pd only. It's a pity that JACK's bufsize can not be set in runtime.
It seems reasonable to expect and accept increased latency if you want to play internet video's etc. together with Pd. Switching between setups would be scriptable to make it easier (also see http://gareus.org/wiki/qjackctl_dbus). But for the moment, I even get stuck many times when switching 'by hand'. Apparently, the order of operations is very critical. If it goes wrong, getting the d-bus error from JACK I haven't found another option than kill the jackdbus process and try again.
Katja
On Mon, 2013-06-03 at 13:09 +0200, katja wrote:
On Mon, Jun 3, 2013 at 9:04 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2013-06-02 08:51, Jonathan Wilkes wrote:
Of course these are just the latencies in the settings-- I haven't done the actual measurements yet.
it would be interesting to have actual measurements. everything else is wild speculation.
Right. I would propose the following measurement protocol:
(setup/usecase A: Pd only through ALSA)
- In Pd using ALSA backend, run sine test signal in 'Media > Test
Audio and Midi...' 2. Set Pd's buffer to lowest possible value such that there are no I/O error messages or audible dropouts during 'normal Pd use', that is, while clicking (radio)buttons or switching between already loaded Pd windows. 3. For this nominal latency setting, measure actual roundtrip latency via line loopback or speaker / mic loopback, using patch latency-tester2.pd which was attached to my May 29 post in this thread.
(setup/usecase B: Pd and PulseAudio through JACK/ALSA) 4. Set up a routing with Pd and PulseAudio as JACK clients. 5. In Pd, run the sine test signal. Simultaneously, play this video in a browser while routing it's sound through PulseAudio / JACK: http://www.youtube.com/watch?v=_63Cc6vPFVI&feature=youtu.be 6. For this combination, get the lowest nominal latency in Jack such that there are no I/O errors in Pd, or audible dropouts in either audio signal. JACK must be restarted for a new buffer setting to take effect. This is the most time-consuming aspect of the measurement. 7. For this routing and settings, measure the actual roundtrip latency through Pd.
- Report nominal + measured latencies for setup A and B, together
with relevant hardware and system info.
My results for Panasonic CF-19 1 GHz Core2Duo, Xubuntu 12.04, built-in soundcard, no preemptive kernel:
- setup/usecase A: 15 ms buffer in Pd, 18 ms measured roundtrip latency
- setup/usecase B: 15 ms buffer in Pd, 23.2 ms (2*512 samples) buffer
in JACK, 49.3 ms measured rountrip latency through Pd
My results forIntel Core 2 Duo T8300 2.4GHz, Ubuntu 12.04 i386 (3.2.0-44-lowlatency-pae)
HDA Intel --------- - usecase A: blocksize 128 in Pd, measured roundtrip 10ms - usecase B: 5.9ms (2frames, 128fr/period), measured roundtrip 14.9ms
HDSP RPM with cardbus --------------------- - usecase A: blocksize 128 in Pd, measured roundtrip 10ms - usecase B: 5.9ms (2frames, 128fr/period), measured roundtrip 14.9ms
Some notes: Whether pulse server was connected to jackd didn't have any influence at all on the best working jackd settings. Either I could start jackd or not. When jackd was running, I didn't get any drop-outs, with or without pulse connected as client. The buffer(ms) setting in Pd doesn't have any influence on the effective latency on my box, with both cards. That is why I reported only the blocksize, which seems the only parameter to have any effect on latency. With Pd connected to jackd, even blocksize doesn't change anything.
Unfortunately, my expensive soundcard does not perform any better than the built-in, regarding latency. It seems this is a regression in the alsa from my Ubuntu version. I remember I was able to set a lower value for frames/period, 32 and 64 have been also working in previous versions of Ubuntu, with the same laptop and the same HDSP card.
Nice latency measurement patch, btw. There is one smallish issue with it. When testing low latency setups, the latency patch itself causes drop-outs because of the 1-10000 loop executed in zero logical time.
Roman
On Wed, Jun 5, 2013 at 2:16 PM, Roman Haefeli reduzent@gmail.com wrote:
[...]
Right. I would propose the following measurement protocol:
(setup/usecase A: Pd only through ALSA)
- In Pd using ALSA backend, run sine test signal in 'Media > Test
Audio and Midi...' 2. Set Pd's buffer to lowest possible value such that there are no I/O error messages or audible dropouts during 'normal Pd use', that is, while clicking (radio)buttons or switching between already loaded Pd windows. 3. For this nominal latency setting, measure actual roundtrip latency via line loopback or speaker / mic loopback, using patch latency-tester2.pd which was attached to my May 29 post in this thread.
(setup/usecase B: Pd and PulseAudio through JACK/ALSA) 4. Set up a routing with Pd and PulseAudio as JACK clients. 5. In Pd, run the sine test signal. Simultaneously, play this video in a browser while routing it's sound through PulseAudio / JACK: http://www.youtube.com/watch?v=_63Cc6vPFVI&feature=youtu.be 6. For this combination, get the lowest nominal latency in Jack such that there are no I/O errors in Pd, or audible dropouts in either audio signal. JACK must be restarted for a new buffer setting to take effect. This is the most time-consuming aspect of the measurement. 7. For this routing and settings, measure the actual roundtrip latency through Pd.
- Report nominal + measured latencies for setup A and B, together
with relevant hardware and system info.
My results for Panasonic CF-19 1 GHz Core2Duo, Xubuntu 12.04, built-in soundcard, no preemptive kernel:
- setup/usecase A: 15 ms buffer in Pd, 18 ms measured roundtrip latency
- setup/usecase B: 15 ms buffer in Pd, 23.2 ms (2*512 samples) buffer
in JACK, 49.3 ms measured rountrip latency through Pd
My results forIntel Core 2 Duo T8300 2.4GHz, Ubuntu 12.04 i386 (3.2.0-44-lowlatency-pae)
HDA Intel
- usecase A: blocksize 128 in Pd, measured roundtrip 10ms
- usecase B: 5.9ms (2frames, 128fr/period), measured roundtrip 14.9ms
HDSP RPM with cardbus
- usecase A: blocksize 128 in Pd, measured roundtrip 10ms
- usecase B: 5.9ms (2frames, 128fr/period), measured roundtrip 14.9ms
Some notes: Whether pulse server was connected to jackd didn't have any influence at all on the best working jackd settings. Either I could start jackd or not. When jackd was running, I didn't get any drop-outs, with or without pulse connected as client.
Just to make sure: did you also play the internet video, and get uncompromised quality for both audio signals with those settings?
The buffer(ms) setting in Pd doesn't have any influence on the effective latency on my box, with both cards. That is why I reported only the blocksize, which seems the only parameter to have any effect on latency. With Pd connected to jackd, even blocksize doesn't change anything.
This is weird, eh? I guess the Media > Audio Settings > Delay(msec) sets Pd's buffer size (rounded or truncated to an integer number of blocks), when it's using ALSA. Anyway this setting normally influences measured latency in a linear fashion. When Pd goes through JACK instead, it seems that Pd's buffer size setting is irrelevant because JACK's buffer is forwarded to Pd.
Unfortunately, my expensive soundcard does not perform any better than the built-in, regarding latency. It seems this is a regression in the alsa from my Ubuntu version. I remember I was able to set a lower value for frames/period, 32 and 64 have been also working in previous versions of Ubuntu, with the same laptop and the same HDSP card.
Nice latency measurement patch, btw. There is one smallish issue with it. When testing low latency setups, the latency patch itself causes drop-outs because of the 1-10000 loop executed in zero logical time.
That is not elegant indeed, even though the loop comes after the data is recorded. I could not find an alternative for the loop, using vanilla objects. If it could be broken in parts, your [nbuntil] solution could help.
Katja
________________________________ From: Roman Haefeli reduzent@gmail.com To: pd-dev@iem.at Sent: Wednesday, June 5, 2013 8:16 AM Subject: Re: [PD-dev] jack dbus?
The buffer(ms) setting in Pd doesn't have any
influence on the effective latency on my box, with both cards. That is why I reported only the blocksize, which seems the only parameter to have any effect on latency. With Pd connected to jackd, even blocksize doesn't change anything.
When using the ALSA backend the entry widget labeled "delay" should have an effect. Try setting it to 1 (ms)-- does it cause audio dropouts?
-Jonathan
-
IOhannes m zmoelnig -
Jonathan Wilkes -
Kaj Ailomaa -
katja -
Roman Haefeli