Re: Jackdbus and pulse
On Fri, 11 Jan 2013 14:12:50 +0100, David Henningsson wrote: Hi, It took some time, but I believe I was actually able to trace it down. It turned out PulseAudio released the device, but then immediately grabbed it again. There are secondary errors too; such as when jackd2 grabs the DBus name but then fails on the hw:0 device, it does not release the DBus name properly, which made the debugging harder. Patch reference: http://lists.freedesktop.org/archives/pulseaudio-discuss/2013-January/015823.html Fantastic :) -- Ubuntu-Studio-devel mailing list Ubuntu-Studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: Jackdbus and pulse
Hi, It took some time, but I believe I was actually able to trace it down. It turned out PulseAudio released the device, but then immediately grabbed it again. There are secondary errors too; such as when jackd2 grabs the DBus name but then fails on the hw:0 device, it does not release the DBus name properly, which made the debugging harder. Patch reference: http://lists.freedesktop.org/archives/pulseaudio-discuss/2013-January/015823.html -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic -- Ubuntu-Studio-devel mailing list Ubuntu-Studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: Jackdbus and pulse
On Thu, January 10, 2013 12:14 am, David Henningsson wrote: > On 01/10/2013 07:54 AM, Len Ovens wrote: >> >> On Wed, January 9, 2013 7:28 pm, David Henningsson wrote: >>> On 01/10/2013 12:46 AM, Len Ovens wrote: >> I have played around with this and there is a hack that will work. This is not a fix. When setting up qjackctl, there is a tab called "Options". On that panel there is a line with "Execute script on Startup". If this is enabled and the line: pasuspender sleep 5 & >>> >>> Interesting; I didn't think this would work, it probably shouldn't - >>> pasuspender should suspend all sinks, including the JACK sink. >>> >>> It must be because the JACK sink is created *after* pasuspender starts, >>> would be the reason why it is not suspended properly. >> >> That is the pre-start script in qjackctl. > > Which should be removed/changed, I talked to Kaj about this on IRC a few > days ago. Sorry I may not have been clear. I put it there for testing. I do not think it is there by default. There are two startup script places available in qjackctl. One just before the server starts and one after it is running (for things like a2j or zita-a2j). >>> To fix it in the right way you need to figure out why this happens in >>> the first place - I mean, it could be either one of these three: >>> >>> 1) PulseAudio does not release the device before answering on dbus >>> 2) Jackd2 does not wait for dbus answer before opening the device >>> 3) The kernel (or alsa-lib) does not release the device properly before >>> returning from snd_pcm_close. >> >> It looks like ... 4) > > Thanks for looking into it. Sorry I didn't add anything useful. At least I learned something. As another note, once jack fails, even using pasuspender will not allow jack to start, I have to do a jack_control exit first... Let me check if a stop will work...No has to be exit. So jack continues to communicate with dbus even though it is (semi) crashed. > It would be interesting to know "sudo fuser -v /dev/snd/pcm*" at exactly > this point in time, because it should be unused. I can't do it at exactly any time. As fast as my fingers move, it shows pulse owns it till jack tries to start, then no-one. It stays as no-one till I try to start jack again, or jack exit. I don't know if a bash loop (time, fuser, loop) would be fast enough to catch something. Or if it would change things with more cpu/disk/whatever use. -- Len Ovens www.OvenWerks.net -- Ubuntu-Studio-devel mailing list Ubuntu-Studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: Jackdbus and pulse
On 01/10/2013 07:54 AM, Len Ovens wrote: On Wed, January 9, 2013 7:28 pm, David Henningsson wrote: On 01/10/2013 12:46 AM, Len Ovens wrote: I have played around with this and there is a hack that will work. This is not a fix. When setting up qjackctl, there is a tab called "Options". On that panel there is a line with "Execute script on Startup". If this is enabled and the line: pasuspender sleep 5 & Interesting; I didn't think this would work, it probably shouldn't - pasuspender should suspend all sinks, including the JACK sink. It must be because the JACK sink is created *after* pasuspender starts, would be the reason why it is not suspended properly. That is the pre-start script in qjackctl. Which should be removed/changed, I talked to Kaj about this on IRC a few days ago. The word devices caught my eye. It seemed to mean physical devices not just backends. Anyway I figured once jack had the device I could unsuspend pulse and because jack already had it, pulse would not be able to take it back. That seemed to be true and pulse seemed to feel jack-sink was the best option to stream audio to. That is why I felt the sleep option should work fine. Ah; yes, that's true, pasuspender just runs for a tiny while, not during the entire jackd process. know if pasuspender uses dbus to tell PA to release HW devices? It uses PA's native protocol (which in turn uses unix sockets for communication, and SHM for memory tranfers). Hmm, ok I can't conclude anything from that then. To fix it in the right way you need to figure out why this happens in the first place - I mean, it could be either one of these three: 1) PulseAudio does not release the device before answering on dbus 2) Jackd2 does not wait for dbus answer before opening the device 3) The kernel (or alsa-lib) does not release the device properly before returning from snd_pcm_close. It looks like ... 4) Thanks for looking into it. Something interesting happens in the jack logfile, The time stamps are not in order. The logging that qjackctl captures seems to come from different places (different colours too). Here is a section of the log where it fails: (my comments are indented) 17:53:18.689 D-BUS: JACK server could not be started. Sorry This looks like the first line, but it is not. D-BUS was free to write logs sooner thats all. Now we have quite a normal jack startup. Wed Jan 9 17:53:17 2013: Starting jack server... If you actually have two instances of jackdbus, shouldn't you have two rows of "Starting jack server..." too? Wed Jan 9 17:53:18 2013: JACK server starting in realtime mode with priority 10 Wed Jan 9 17:53:18 2013: control device hw:1 Wed Jan 9 17:53:18 2013: control device hw:1 Wed Jan 9 17:53:18 2013: Acquired audio card Audio1 Hmm, we just aquired hw:1 "Audio1" likely refers to the dbus reservation, whereas "hw:1" refers to the kernel object. "hw:1" is translated by alsa-lib into /dev/snd/pcmC1D0p (playback), /dev/snd/pcmC1D0c (capture), or /dev/snd/controlC1 (mixer). The mixer can be opened by several apps simultaneously, but playback and capture are for one app at a time. Wed Jan 9 17:53:18 2013: creating alsa driver ... hw:1|hw:1|64|2|48000|0|0|nomon|swmeter|-|32bit Wed Jan 9 17:53:18 2013: control device hw:1 Up till here it looked good Then (no time stamp, I assume this means direct error output from Qjackctl as this is the same output I see if I use jack_control. Cannot connect to server socket err = No such file or directory Cannot connect to server request channel jack server is not running or cannot be started It was running how did it stop? Now this looks like a failed start up... device in use. But, jack was Already able to acquire it. Wed Jan 9 17:53:18 2013: [1m[31mERROR: ATTENTION: The playback device "hw:1" is already in use. Please stop the application using it and run JACK again[0m Again notice the difference between "Audio1" and "hw:1". It would be interesting to know "sudo fuser -v /dev/snd/pcm*" at exactly this point in time, because it should be unused. Wed Jan 9 17:53:18 2013: [1m[31mERROR: Cannot initialize driver[0m Wed Jan 9 17:53:18 2013: [1m[31mERROR: JackServer::Open failed with -1[0m Wed Jan 9 17:53:18 2013: [1m[31mERROR: Failed to open server[0m Wed Jan 9 17:53:19 2013: Saving settings to "/home/joe/.config/jack/conf.xml" ... 17:53:23.992 Could not connect to JACK server as client. - Overall operation failed. - Unable to connect to server. Please check the messages window for more info. Cannot connect to server socket err = No such file or directory Cannot connect to server request channel jack server is not running or cannot be started Ok, this is what seems to happen. This is my hypothesis: - Qjackctl sends a message via DBUS to start jack - Jack starts and asks for the device. - pulse gives the device. - jack gets it. - DBUS (on it's own or at the asking of qjackctl) checks
Re: Jackdbus and pulse
On Wed, January 9, 2013 7:28 pm, David Henningsson wrote: > On 01/10/2013 12:46 AM, Len Ovens wrote: >> I have played around with this and there is a hack that will work. This >> is >> not a fix. When setting up qjackctl, there is a tab called "Options". On >> that panel there is a line with "Execute script on Startup". If this is >> enabled and the line: >> >> pasuspender sleep 5 & > > Interesting; I didn't think this would work, it probably shouldn't - > pasuspender should suspend all sinks, including the JACK sink. > > It must be because the JACK sink is created *after* pasuspender starts, > would be the reason why it is not suspended properly. That is the pre-start script in qjackctl. I first tried opening a terminal and just doing pasuspender bash. That way I could end it when I wanted by typing exit. It worked that way too. I was surprised that even though pulse was suspended, the PA/jack bridge still connected. I read the man page where I found out: "pasuspender is a tool that can be used to tell a local PulseAudio sound server to temporarily suspend access to the audio devices..." The word devices caught my eye. It seemed to mean physical devices not just backends. Anyway I figured once jack had the device I could unsuspend pulse and because jack already had it, pulse would not be able to take it back. That seemed to be true and pulse seemed to feel jack-sink was the best option to stream audio to. That is why I felt the sleep option should work fine. >> know if pasuspender uses dbus to tell >> PA to release HW devices? > > It uses PA's native protocol (which in turn uses unix sockets for > communication, and SHM for memory tranfers). Hmm, ok I can't conclude anything from that then. > To fix it in the right way you need to figure out why this happens in > the first place - I mean, it could be either one of these three: > > 1) PulseAudio does not release the device before answering on dbus > 2) Jackd2 does not wait for dbus answer before opening the device > 3) The kernel (or alsa-lib) does not release the device properly before > returning from snd_pcm_close. It looks like ... 4) Something interesting happens in the jack logfile, The time stamps are not in order. The logging that qjackctl captures seems to come from different places (different colours too). Here is a section of the log where it fails: (my comments are indented) 17:53:18.689 D-BUS: JACK server could not be started. Sorry This looks like the first line, but it is not. D-BUS was free to write logs sooner thats all. Now we have quite a normal jack startup. Wed Jan 9 17:53:17 2013: Starting jack server... Wed Jan 9 17:53:18 2013: JACK server starting in realtime mode with priority 10 Wed Jan 9 17:53:18 2013: control device hw:1 Wed Jan 9 17:53:18 2013: control device hw:1 Wed Jan 9 17:53:18 2013: Acquired audio card Audio1 Hmm, we just aquired hw:1 Wed Jan 9 17:53:18 2013: creating alsa driver ... hw:1|hw:1|64|2|48000|0|0|nomon|swmeter|-|32bit Wed Jan 9 17:53:18 2013: control device hw:1 Up till here it looked good Then (no time stamp, I assume this means direct error output from Qjackctl as this is the same output I see if I use jack_control. Cannot connect to server socket err = No such file or directory Cannot connect to server request channel jack server is not running or cannot be started It was running how did it stop? Now this looks like a failed start up... device in use. But, jack was Already able to acquire it. Wed Jan 9 17:53:18 2013: [1m[31mERROR: ATTENTION: The playback device "hw:1" is already in use. Please stop the application using it and run JACK again[0m Wed Jan 9 17:53:18 2013: [1m[31mERROR: Cannot initialize driver[0m Wed Jan 9 17:53:18 2013: [1m[31mERROR: JackServer::Open failed with -1[0m Wed Jan 9 17:53:18 2013: [1m[31mERROR: Failed to open server[0m Wed Jan 9 17:53:19 2013: Saving settings to "/home/joe/.config/jack/conf.xml" ... 17:53:23.992 Could not connect to JACK server as client. - Overall operation failed. - Unable to connect to server. Please check the messages window for more info. Cannot connect to server socket err = No such file or directory Cannot connect to server request channel jack server is not running or cannot be started Ok, this is what seems to happen. This is my hypothesis: - Qjackctl sends a message via DBUS to start jack - Jack starts and asks for the device. - pulse gives the device. - jack gets it. - DBUS (on it's own or at the asking of qjackctl) checks that jack is running. - Jack is busy getting started and does not respond (or not soon enough). - DBUS does what it normally does when it can't contact a service and starts jackdbus (again) - Jack is already (still) running and has the device - the new jack instance tries to get the device and fails. - Anything that wants to talk to jack gets the address from DBUS of the new jack instance and fails or has DBUS try to start a new instance which fail
Re: Jackdbus and pulse
On 01/10/2013 12:46 AM, Len Ovens wrote: We have lately been having trouble with our pulse/jackdbus setup. When I first installed 12.04 starting Jackdbus with qjackctl or jack_control would stop whatever pulse was doing and use the port. Somewhere between there and here this no longer works right. Sometimes if the session has just started, and pulse has not been used to stream anything, jack still works this way, but for sure once pulse has been used or is streaming, Jack will fail to start because it can not get access to the device pulse is using. What is supposed to happen: Jackdbus uses dbus to tell pulseaudio to release the device jack wishes to connect to. This does appear to happen, at least audio stops going to the device and the timer on the streaming app stops just as in the case of a blocked port. However, jack fails to get the port. (once in a long while it "just works") I have played around with this and there is a hack that will work. This is not a fix. When setting up qjackctl, there is a tab called "Options". On that panel there is a line with "Execute script on Startup". If this is enabled and the line: pasuspender sleep 5 & Interesting; I didn't think this would work, it probably shouldn't - pasuspender should suspend all sinks, including the JACK sink. It must be because the JACK sink is created *after* pasuspender starts, would be the reason why it is not suspended properly. Added, everything just works so long as jack is started with qjackctl. I tested this by using Audacious to play some songs through pulse. On starting jack with qjackctl there is a brief silence and then the stream switches over to jack-sink and continues to stream through jack. Stopping jack works just fine too with the stream switching back to the device. Davis I CCed this to you because I know you have a better understanding of pulse than me. Would you (or anyone) know if pasuspender uses dbus to tell PA to release HW devices? It uses PA's native protocol (which in turn uses unix sockets for communication, and SHM for memory tranfers). If so then it would appear that PA is working but jackdbus is not waiting long enough, or that PA is ack the dbus message before it has completed releasing the port. Maybe it is the right thing for PA to do even... Dbus may not like to wait around while PA does stuff. Anyway, an answer to this will give me a good idea which package to apply the bug against... and maybe see if a patch can be made. My inclination is to bug jackd2. The patch would be to delay jackd for a short period (half second?) after getting a dbus ack before attempting to use the device. I will try to figure it out myself, but am not great with c++, most of my programing has been c, and not for a while now. There is indeed a timing issue, which I never tracked down and fixed. To be pragmatic, I guess you can insert random delays wherever it works, but beware - timings are very different between hardware, so the timings that work for you might not work everywhere else. To fix it in the right way you need to figure out why this happens in the first place - I mean, it could be either one of these three: 1) PulseAudio does not release the device before answering on dbus 2) Jackd2 does not wait for dbus answer before opening the device 3) The kernel (or alsa-lib) does not release the device properly before returning from snd_pcm_close. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic -- Ubuntu-Studio-devel mailing list Ubuntu-Studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: Jackdbus and pulse
On Wed, January 9, 2013 3:46 pm, Len Ovens wrote: > > pasuspender sleep 5 & Actually pasuspender sleep 1 & Works just as good. -- Len Ovens www.OvenWerks.net -- Ubuntu-Studio-devel mailing list Ubuntu-Studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Jackdbus and pulse
We have lately been having trouble with our pulse/jackdbus setup. When I first installed 12.04 starting Jackdbus with qjackctl or jack_control would stop whatever pulse was doing and use the port. Somewhere between there and here this no longer works right. Sometimes if the session has just started, and pulse has not been used to stream anything, jack still works this way, but for sure once pulse has been used or is streaming, Jack will fail to start because it can not get access to the device pulse is using. What is supposed to happen: Jackdbus uses dbus to tell pulseaudio to release the device jack wishes to connect to. This does appear to happen, at least audio stops going to the device and the timer on the streaming app stops just as in the case of a blocked port. However, jack fails to get the port. (once in a long while it "just works") I have played around with this and there is a hack that will work. This is not a fix. When setting up qjackctl, there is a tab called "Options". On that panel there is a line with "Execute script on Startup". If this is enabled and the line: pasuspender sleep 5 & Added, everything just works so long as jack is started with qjackctl. I tested this by using Audacious to play some songs through pulse. On starting jack with qjackctl there is a brief silence and then the stream switches over to jack-sink and continues to stream through jack. Stopping jack works just fine too with the stream switching back to the device. Davis I CCed this to you because I know you have a better understanding of pulse than me. Would you (or anyone) know if pasuspender uses dbus to tell PA to release HW devices? If so then it would appear that PA is working but jackdbus is not waiting long enough, or that PA is ack the dbus message before it has completed releasing the port. Maybe it is the right thing for PA to do even... Dbus may not like to wait around while PA does stuff. Anyway, an answer to this will give me a good idea which package to apply the bug against... and maybe see if a patch can be made. My inclination is to bug jackd2. The patch would be to delay jackd for a short period (half second?) after getting a dbus ack before attempting to use the device. I will try to figure it out myself, but am not great with c++, most of my programing has been c, and not for a while now. -- Len Ovens www.OvenWerks.net -- Ubuntu-Studio-devel mailing list Ubuntu-Studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
