[00:04] <Len-nb> zequence, kdenlive pushed iso size up 0.1G, no complaints from me.
[00:05] <Len-nb> Now that we have crossed the kde libs bridge... there may be other kde apps that make sense.  ;)
[00:06] <Len-nb> It seems to me there was a photography app we did not include for the same reason.
[00:13] <Len-nb> digikam maybe?
[00:34] <falktx> digikam is very nice
[00:34] <falktx> k3b maybe?
[00:36] <Len-nb> :) I wondered how log it would take .
[00:37] <Len-nb> I never did check if bassero got fixed.
[00:38] <Len-nb> *brasero
[00:38] <Len-nb> I have heard good things about K3B though.
[00:39] <Len-nb> Still would like something like gdcmaster.
[03:00]  * holstein is about to paste some info here
[03:01] <holstein> 21:59 < las> Thu Dec 27 20:15:43 2012: Starting jack server... Thu Dec 27 20:15:43 2012: JACK server starting in realtime mode  with priority 1 Thu Dec 27 20:15:43 2012: control device hw:0 Thu Dec 27 20:15:43 2012: control device hw:0 Thu  Dec 27 20:15:43 2012: ERROR: Failed to acquire device name : Audio0 error : Cannot allocate memory Thu Dec 27 
[03:01] <holstein>  20:15:43 201: ERROR: Audio device hw:0 cannot be 1acquired... Thu Dec 27 20
[03:01] <holstein> appologies for the formatting.. i just want us to look it over
[03:02] <holstein> 21:57 < las> holstein: it apears from several reports here and on #jack recently that ub 12.04 has been packaged so that if  you only install pulse + jack, device negotiation does not work
[03:02] <holstein> 22:00 < las> holstein: then you install pulseaudio-jack-sink or whatever it is called and the "Failed to acquire device name"  starts working
[03:03] <holstein> ScottL__ Len-nb zequence  ...any ideas?
[03:03] <holstein> las says its a packaging issue on our end
[03:04] <holstein> if this is the case, we could just ask JACK to pull in the *-sink package as a dep
[03:19] <ScottL__> holstein, i don't have a clue to be honest
[03:20] <ScottL__> are they installing jack & pulse in vanilla ubuntu 12.04, holstein ?
[04:15] <falktx> why not just put the pa*-jack stuff in the metas? 
[06:47] <len-1304> I had ubiquity use our logo for ubuntustudio partitions today.
[06:48] <len-1304> Just waiting for the -settings to get uploaded.
[09:33] <zequence> holstein: That's more of a packaging issue on Debian end
[09:33] <zequence> and I'm not sure if that's a problame with jackd or pulseaudio
[10:05] <zequence> Len-nb: training.linuxfoundation.org/free-linux-training/linux-tutorials-and-videos/diagnose-power-consumption-with-powertop
[10:24] <zequence> OSX apps on Linux http://darling.dolezel.info/en/Darling
[13:09] <scott-work> holstein: did we ever find out if people experiencing the pulse-jack issue were starting with vanilla ubuntu? also do we know what card is being used?
[13:10] <scott-work> in my half-awake/half-asleep state before the alarm i thought about the audio group as well
[13:10] <scott-work> i'm not sure what data laz is using to determine this may be a packaging bug
[14:10] <len-1304> zequence, scott-work I think what is happening when installing jackd over a generic kernel is that it does not even ask if it will run realtime because it can't.
[14:10] <len-1304> So the lowlatency kernel needs to be installed _and_ booted before jackd is installed
[14:12] <len-1304> or we need a script that fixes things or informs the user what they need to do.
[14:14] <len-1304> It could be called packaging, except that jackd can run in a non-rt environment.
[14:14] <len-1304> For example just to allow the use of a FW audio IF.
[14:15] <len-1304> The thing is, there is no such thing as having jackd just work out of the box in all conceivable applications.
[14:19] <len-1304> The instructions for putting US audio over vanilla should be:
[14:20] <len-1304> install lowlatency kernel
[14:20] <len-1304> remove generic kernel
[14:20] <len-1304> then install metas
[14:20] <len-1304> oopps... reboot then install metas.
[14:26] <scott-work> hmmmm. i have installed jack over a vanilla install before, added myself to the audio group, and had jack start with -rt privileges
[14:27] <scott-work> otherwise jack throw error messages and fail to start
[14:27] <scott-work> i wonder if something has changed
[14:45] <len-1304> scott-work, it seems if jackd can't lock memory for buffering when in RT mode it fails.
[14:46] <len-1304> Rather than trying with non-lockable memory and starting in non-rt it just fails.
[14:47] <len-1304> but it doesn't stop at the memory alloc, it keeps going and because there is no memory set aside for the device, the device is "not there"
[14:50] <len-1304> With jackd, the first error message has to be dealt with first, but most users look at the last error message. (which they understand)
[16:08] <zequence> len-1304: scott-work There are different issues being discussed here, but what las was talking about was..
[16:08] <zequence> when starting jackd, pulseaudio should release the audio device
[16:08] <zequence> with or without pulseaudio-module-jack
[16:08] <zequence> as for realtime privilege, that is another issue all together
[16:10] <zequence> I don't know what code was responsible in letting jackd grab the card from PA in the past, but it seems this may have changed recently
[16:10] <zequence> There is also the bug with jackdbus not closing properly to take into account
[16:11] <zequence> and to clarify, I'm not talking about the pulseaudio-module-jack module
[16:11] <zequence> or, it is not a factor in this problem
[16:12] <zequence> It should only need to be installed if one wants to have PA auto connect to jack
[16:15] <zequence> len-1304: jackd realtime operation is not depending on the kernel
[16:15] <zequence> you can achieve realtime with any kekrnel
[16:15] <zequence> kernel*
[16:16] <zequence> It's just that you get better performance at lower latencies with -lowlatency
[16:17] <zequence> installing jackd is the same on any kernel
[16:47] <scott-work> zequence: "letting jackd grab the card from PA" - i believe starting at 8.04, qjackctl including a wrapper script that would run 'pasuspender' that would suspend pulse audio
[16:48] <scott-work> i forget when, but i think it was when jackd starting using dbus that this practice stopped, david h. made that change i believe
[16:49] <scott-work> zequence: also, your description of -rt behaviour aligns with my experience as well with regards to kernels, the -pa module
[17:15] <zequence> the use of the wrapperpper did stop at some point
[17:15] <zequence> But, I don't think it was related to dbus
[17:15] <zequence> and definately not pulseaudio-module-jack
[17:18] <zequence> starting jackd (not jackdbus) and without pulseaudio-module-jack lets jackd grab the audio device from pulseaudio on 12.04
[17:19] <scott-work> ach. webchat dropped me and i missed conversation. i'll check logs.
[17:19] <zequence> scott-work: you didn't miss anything
[17:19] <scott-work> oh. good :)
[17:20] <zequence> the only time when it fails is when PA is using the device for something
[17:21] <scott-work> zequence: oh. i just thought of something. qjackctl uses dbus by default (i believe). if paul (and others) are starting jackd wihtout qjackctl then we may have a problem
[17:21] <zequence> scott-work: It's not related to qjackctl
[17:22] <zequence> jackd, without dbus grabs the card on 12.04. no problem. unless PA is busy streaming audio to the device
[17:23] <scott-work> does that address paul's question or error? i don't remember the exact error actually
[17:23] <zequence> I don't think las actually knows how jackd is configured on Debian/Ubuntu
[17:24] <zequence> scott-work: las arguments about Debian packaging problems holds little weight without a further explanation of the problem. Right now, it could be someone just misunderstood something, and there's no bug at all
[17:24] <zequence> what holstein pasted about the error does not tell much
[17:25] <zequence> Let me check jackd behaviour on 12.10 and 13.04 when I come home
[17:25] <zequence> I'm still in Switzerland
[17:27] <zequence> I remember someone saying something about the device grabbing being coded either into jackd or PA
[17:27] <zequence> on 12.04, it works as expected
[17:33] <scott-work> my thought was that if debian/ubuntu expected users to default to qjackctl to start/use jack and therefore use dbus, then perhaps pulse was configured to only play nice with dbus. therefore, if paul or others start jack from command line or ardour without dbus then pulse may not let the device go
[17:33] <scott-work> of course, i am neither an expert or played much with pulse/jack in recent version as i had in the past
[17:34] <zequence> scott-work: As I said, jackd starts just fine from the command line
[17:34] <zequence> And I don't think las uses Ubuntu. That's the impression I get
[17:35] <zequence> I still need to check 12.10 and 13.04. There's a newere pulseaudio to consider also
[17:40] <zequence> seems that jackd1 does not start for me either way, and it objects about bad settings, but by looking in the wrong place
[17:43] <zequence> the jackd1 problem is unrelated to PA alltogether though
[17:48] <zequence> falktx: Do you know how jackd negotiates with pulseaudio to have it release the audio device
[17:49] <falktx> I know it uses dbus
[17:49] <falktx> so it only works with jack2 and with dbus version
[17:50] <zequence> falktx: but it's not just when starting jackdbus. also when starting jackd (jackd2)
[17:51] <falktx> no
[17:51] <falktx> starting jackd the usual way, ie:
[17:51] <falktx> jackd -d alsa ...
[17:52] <falktx> will not work
[17:52] <falktx> if it does, it's pure luck
[17:52] <zequence> falktx: It works everytime, unless PA is streaming audio
[17:53] <falktx> afaik it's not how it was supposed to work
[17:53] <falktx> this are different things then
[17:53] <falktx> the jackdbus reservation trick works even when pulseaudio apps are running
[17:54] <zequence> I'm not talking about the PA sink and source. Just having PA release the audio device
[17:54] <falktx> in which case pulseaudio lets jackdbus start with its device and then pulseaudio auto-activates its jack PA sink/source
[17:54] <falktx> oh, ok
[17:58] <zequence> maybe PA is not actually grabbing it, when idle. I'll look into it some day. Now I'm eating pancakes
[18:00] <falktx_> damn my internet
[21:19] <zequence> In jackd2 source, there's some Poettering code, for letting PA and jackd negotiate for an audio device
[21:19] <zequence> http://git.0pointer.de/?p=reserve.git;a=blob;f=reserve.txt
[21:20] <zequence> in the jackd2 source, it's in dbus/reserve.c, dbus/reserve.h
[21:23] <zequence> Whatever audio server that has the highest priority (not sure yet how and where prio is set for this particular parameter), will get control of the audio devicce
[21:25] <zequence> It's done through dBus, but this is not to be mixed up with pulseaudio-module-jack, which is something entirely different
[21:30] <astraljava> Damn. I've been away for the True Programming for too long. Your analytical bisecting of the audio stack makes me wet myself. I need to get back in the game, NOW!
[21:32] <zequence> :(. I wish one had more lives to spend on learning this stuff..
[21:35] <astraljava> Indeed. I have had the passion to really get into the linux audio for so long, but I've had too many obstacles (mostly in my mind). And yet again I'm fighting professional issues, that take away from the technical pool, not allowing to concentrate on Stuff That Matter™.