[03:42] <ailo> len-dt: I think we just may need to improve functionality for pulseaudio-jack-module
[03:42] <ailo> pactl can load and unload pulseaudio modules, but I don't think that is the way to go
[03:46] <ailo> When you load the module, you get it's ID, so that helps creating a script that loads/onloads it at will
[03:47] <ailo> Also, pasuspender could still be used
[03:47] <ailo> The best thing would be just to improve the module
[03:48] <ailo> Either with feedback to the developers, or try make changes/patches for it
[03:50] <ailo> I need to look more at how it works
[03:50] <ailo> Right now, I just installed jackd2, but I don't seem to be able to use the PA module
[03:51] <ailo> All PA sinks and sources are suspended however :O
[03:51] <ailo> I see that from: pactl list
[03:57] <ailo> Restarting PA was enough to get the bridge working again
[04:06] <ailo> len-dt: The module itself is coded by David Henningson
[04:09] <ailo> len-dt: Also, it will be interesting to see how the new qjackctl is improved regarding jackdbus
[13:55] <len-dt> ailo, I agree loading/unloading PA modules is not the best, It would be better if the module could be turned off/on.
[13:56] <len-dt> I don't know if that is possible... or if it is, what other problems might be there.
[13:58] <len-dt> I think it would require the module to have it's own connection to dbus or for the module to be more integrated with pulse itself so it could use PA's dbus connection.
[13:58] <ailo> len-dt: I don't think there is any way to turn it off. In effect, unloading the module is turning it off. But what I meant as a better alternatvive was to improve how the module interacts with jack, and make sure it does nothing until you want it to connect.
[13:59] <ailo> I would guess the jack sink and jack source are typical jack apps
[13:59] <ailo> And those should not be loaded, until used
[13:59] <len-dt> ailo, pasuspender doesn't gain anything that I can tell.
[14:01] <ailo> To imrove the module, either we try to find a way by coding it, or we communicate to the developer side.
[14:02] <len-dt> PA-jack bridge should only be used in a very few places. One is recording from gstreamer... I would prefer to see PA improved to allow patching an output to an input for that.
[14:02] <len-dt> The other is to use PA with firewire stuff.
[14:02] <ailo> You can't anticipate what people will use software for
[14:02] <ailo> But, you can make it behave well
[14:03] <ailo> I think the jack bridge would probably be handy in a lot of situations
[14:03] <len-dt> I don't think the module can be made in such a way as to have PA not affect jack or vis versa.
[14:03] <ailo> Why not?
[14:04] <len-dt> I do think that for it's uses the user just has to accept higher latencies where it works just fine.
[14:04] <len-dt> It has to be that way because the two apps have to be in sync
[14:05] <len-dt> PA when bridged to jack has to sync it's audio to jack
[14:05] <ailo> That is not different from any other software with jack support
[14:06] <ailo> But, by improvement, I was more talking about when you are not using PA
[14:06] <ailo> Right now, jack sink and source are always on, even when they are not used
[14:06] <len-dt> Yes and any other SW that behaves badly can affect any of the software that is using jack at the time.
[14:07] <len-dt> At least that is what I have found.
[14:07] <ailo> PA doesn't need to sync with jack, if it's not connected to jack
[14:07] <len-dt> Right
[14:07] <ailo> There are three modules at play here
[14:07] <len-dt> As soon as the bridge is loaded it has to sync.
[14:08] <len-dt> PA starts feeding jack silence 
[14:08] <len-dt> but that silence has to be in sync
[14:09] <ailo> module-jackdbus-detect, module-jack-sink and module-jack-source
[14:09] <ailo> We only need the jack sink and jack source to be spawn once we connect
[14:09] <ailo> Right now they are on, even if we aren't using them
[14:10] <len-dt> The detect module auto loades the other two and unloads them .
[14:10] <ailo> That is what I would like to improve
[14:10] <ailo> Make it not load the sink and source, until you choose jack as sink or source in the PA mixer
[14:10] <len-dt> ailo,  they can't show up on jack as a connectible source unless they are in sync.
[14:11] <ailo> You don't need them to be in sync, until you spawn them
[14:11] <ailo> We'd want jack sink and source to appear in the PA mixer, but not actually be loaded, until chosen
[14:12] <len-dt> The solution (I think) it to have just the module be in sync until PA connects a source to them.
[14:12] <ailo> I also think it's confusing having PA show in jack, when PA is not connected to jack
[14:13] <len-dt> How does the module know when you want it to appear in jack?
[14:13] <ailo> jack is connected to the module, but not PA
[14:13] <ailo> When you choose jack sink or jack source from PA mixer, the sink and source should appear in jack
[14:13] <ailo> That is the way I would do it
[14:14] <ailo> Should probably not take too much coding to make that happen
[14:14] <len-dt> ailo, OK I don't know that I want to be the one to sugest this to David though :-)
[14:15] <ailo> I should probably discuss this option somewhere. Maybe the PA mail list
[14:16] <len-dt> You need to define it really well first
[14:16] <len-dt> Have a use scenario ready.
[14:17] <ailo> The logic is pretty simple. Have PA not interact with jack, until when jack is loaded, and you have chosen jack as either sink or source from PA mixer
[14:17] <ailo> There's no reason for PA to interact with jack, when you are not using it with jack
[14:18] <len-dt> Actually, I would want to be able to choose jack as a sink or source even before jackd was running. If jack is not running it should act the same as a dummy output sending the audio stream to nowhere
[14:19] <ailo> Would you want the same thing for a device, that is no longer there?
[14:20] <len-dt> Yes the logic is very simple, but unless the implementation is well defined what we end up with could be worse.
[14:21] <len-dt> Jack is different from a device. Jack may be expect to vanish and reappear. And a user may wish it to remain as default device if that is their only device because they are using firewire
[14:22] <ailo> Default yes, but not when it's not there. I'd have it auto route to whatever was used before jack was chosen
[14:22] <ailo> And when turning on jack the next time, auto route back to jack
[14:22] <len-dt> you and I differ there
[14:23] <ailo> It would be great if jack could be controlled from the PA mixer, with session control, and connection abilities, simplified, all from the same place
[14:23] <ailo> With a jack addon
[14:24] <len-dt> ailo, jackd could use improvement, PA could too.
[14:26] <len-dt> jackd should (in my opinion) deal directly with two IFs in sync without having to pretend it was all one device in alsa.
[14:27] <len-dt> just as an example.
[14:27] <len-dt> PA should allow patching of its outputs and inputs... 
[14:28] <ailo> len-dt: Btw, there was a post about xruns not being real xruns on the jack devel list. 
[14:28] <len-dt> Yes, I saw that, but anything I can hear is a real one.
[14:29] <ailo> He was using two as one. I think perhaps he's the same guy who talked about that before
[14:30] <ailo> That there may be xruns, but they aren't really causing any trouble
[14:31] <len-dt> The problem with using two as one is that besides all the fake xruns, with some setup jack had to be started a few times before it would work at all. It is not stable.
[14:32] <ailo> I never did much testing myself, but once I did get it going, it just worked for me
[14:32] <ailo> It is however bad that it is so hard to get +8 channels for linux audio
[14:32] <len-dt> yes some people have that experience and it seems other with the same IF don't
[14:33] <ailo> You can daisy-chain firewire devices, and it is said to work alright, but will it sync properly?
[14:33] <ailo> Propably too few people do that sort of thing
[14:34] <len-dt> I don't have any to play with. ailo my short experience in testing has shown me that much of what I read does not work and that what works for me is not universal.
[14:36] <ailo> len-dt: This is why we need to add more machines and devices to the mix. You have usb, I don't. I do have firewire, pci and builtin. And a bunch of machines, older and newer
[14:36] <ailo> If we just do the same tests on all of them, we should start to see patterns
[14:37] <len-dt> that is a start and will at least tell us what is happening with a stock install.
[14:37] <ailo> I have 3 machines + this one hooked up right now. Another 2-3 could be added (notebooks and a netbook)
[14:37] <ailo> If we automate tests, using scripts, it will make things easy enough
[14:38] <len-dt> I wish I could disable the internal sound on my netbook.
[14:39] <len-dt> ailo, I think swappiness should be added to studio controls. It appears the stock setting for ubuntu is wrong for desktops let alone audio
[14:40] <ailo> If the stock settings are wrong for all sorts of desktops, I would recommend changing them by default. But, for further control, sure. Put them in controls
[14:41] <ailo> I still think it's too early to talk about implementation. We just need to go through all tweaks, test them, document them. Decide, and then implement
[14:42] <ailo> If we can make a sketch of the whole thing, as well as further ideas for -controls (administering user realtime privilege, and perhaps installing codecs and stuff like that), we can start making the -controls even before we know exactly what it should control
[14:42] <ailo> But, that's not really an issue as far as testing goes
[14:43] <len-dt> Yes it should be reported as bug/feature request. ubuntu's wiki recommends something different from what ships, so what ships should change or the recommendation should change 
[14:56] <len-dt> There is already a bug: Bug #977319 about this. I just confirmed it. Does it make any difference if more people say it effects them?
[15:02] <ailo> That bug did not have many responses, so I would think so
[15:02] <ailo> Perhaps there are more bugs on the same subject?
[15:03] <len-dt> Bug #516834
[15:04] <len-dt> I think a lot of people don't know they have this problem
[15:11] <ailo> len-dt: Did you read the comments for the last link?
[15:14] <len-dt> I'm doing so... it is fun.
[15:15] <len-dt> It seems that for a machine that is basically out of memory a high swappiness value is better. But how many people have that. Once you have just a bit more memory lower is better.
[15:16] <len-dt> However comment 41 says it all. That is whay there is a new bug.
[15:17] <ailo> len-dt: Not a lot of interest to fix it, seemingly
[15:18] <ailo> There's no stopping US from adding a fic
[15:18] <ailo> fix*
[15:18] <len-dt> ailo, no
[15:18] <len-dt> yes, I think we need to.
[15:18] <ailo> I wonder how other distros does this
[15:18] <len-dt> audio is different enough from even desktop use to warrent it.
[15:19] <len-dt> I would check kubuntu as they seemed to have the most interest in it.
[15:21] <ailo> mint aught to be interested in this, being very desktop orientated
[15:21] <ailo> Fedora, perhaps
[15:22] <len-dt> It seesm the settings guys don't want to change it... should be kernel... kernel says no... and it ends there.
[15:22] <len-dt> If all the *buntus put it in that may change '=_
[15:23] <ailo> I think Fedora also uses 60
[15:24] <ailo> Just found, quote "after upgrading default swappiness in Fedora 11 has been modified to 40 from 60!! "
[15:24] <len-dt> Linux has traditionally been driven by server use.
[15:25] <ailo> https://blueprints.launchpad.net/linuxmint/+spec/swappiness
[15:25] <ailo> Well, that was just a request :)
[15:26] <ailo> I don't think Mint uses their own kernels, so they won't change that either propably
[15:27] <len-dt> it is not a kernel change but a settings change. They can do it in just their own distro.
[15:27] <len-dt> "Swappiness can be reduced by editing /etc/sysctl.conf."
[15:35] <len-dt> Canonical actually gets paid for support by their business users and so that is likely to remain first concern
[22:26] <Len-nb> ailo, our ISO is still not building, what steps can we take?
[22:28] <Len-nb> Looks like a package incompatibility with something xfce4ish but I note xubuntu doesn't have the same problem. They don't seem to have fixed anything either, so it is something we have set up.
[22:30] <Len-nb> Not something we have changed though, so some change in packages we use. I am guessing I will have to do a 12.10 install to find out more... nap first :-)