[00:04] len-dt: I wonder how much one could do to control ladish [00:05] Might be something worth investigating for your workflow panel app [00:13] ailo, Ya, a workflow app needs a rethink. What I had done so far gave a workflow specific menu/panel. I don't think that really is that much of a help beyond the main menu. [00:14] len-dt: It might be possible to use the same components that Gladish uses, and maybe automate some things a bit more. [00:15] It already has all you need to control jack [00:16] If one would like to be really ambitious, one could incorporate PA as well [00:17] Does it control jack better than qjackctl? [00:17] Don't think it has more features, other than the session part [00:18] Perhaps it doesn't get the same bug as qjackctl, when stopping jackdbus [00:18] Need to test it more [00:18] It was the bug I was wondering about. [00:18] For the average user, the control panels are a bit more informative than you'd need them to be [00:19] ailo: https://staging.ubuntustudio.org/tour/audio/ is very nice! [00:19] holstein: Thanks. If you find something badly written, or missing, please do tell. I don't really like adding text to pages like that [00:21] ailo, from your picture of gladish on that page, it looks like it does some patchage stuff too. [00:22] len-dt: I would think it's the same code [00:22] At least I recognize it from a few other apps [00:22] same author then? [00:22] Maybe same tool kit [00:22] I think falktx uses that too for one of his apps [00:26] Generally, starting applications and saving them could be done almost identically to how Gladish does this, but only do it from the panel [00:27] Just that you can't save the projects that are in use. Only connections for the most part [00:27] I would prefer another interface for doing jack settings. One which is much easier to read for novice users [00:27] Seems more confusing to set up jack. [00:28] * len-dt means more confusing than qjackctl [00:28] Just a list of settable variables, yeah [00:29] Would be enough to keep only a few of those visible for a main settings window, and hide the advanced stuff in another tab or whatever. And make sure the user is informed about each setting [00:29] ailo, The term room seems to mean something different than I would expect.. [00:29] Er, yeah. I haven't used that yet :P [00:30] len-dt: You might like to see falktx applications for reference too [00:30] Ya he seems to make more use of it than most people. [00:30] len-dt: http://kxstudio.sourceforge.net/KXStudio:Applications [00:31] One thing lacking in Ubuntu Studio is vst support [00:31] Hard to do probably [00:31] Also, I'm not sure about paths to instruments, and that sort of thing [00:32] I have a link to kxstudio in my bookmarks. Some of it installed on this machine. [00:33] I guess Claudia is the most interesting in this case [00:33] ailo, adding applications to ladish seems to require typing in command line stuff. But maybe I can start it from the menu and it would show up. [00:34] len-dt: Let's say you start an application from your workflow bar. Anything started from there could be started within ladish [00:34] Ya they do. seems jack starts up too [00:35] Can you save them? Let me check. The list doesn't always update, I've notices [00:35] I just started jackrack and all the pieces appeared [00:36] PA sure takes up a lot of real estate [00:38] len-dt: If you start an application normally, it shows up in connections, but you can't save it with the session [00:39] I do seem to have some bugs [00:39] jackdbus is buggy [00:39] Someone said the new version of qjackctl was still having problems shutting down jackdbus [00:40] jack_control does too but because it gets started anew every time it is more resilient. [00:41] It's a bit of a problem, having jackdbus crash like that [00:41] Would be nice to have a "killall" button [00:41] Not nice, but useful [00:41] What all would kill? [00:41] Just jack? [00:41] Don't know. In this case everything jack, as well as ladish [00:42] and or qjackctl I would guess. [00:42] Does the dbus version of jack add that much to things we should even use it? [00:43] Does ladish work without it? [00:43] That I don't know. I think PA's jack sink needs it though. [00:45] Ya, dbus is what they all use to "talk" to each other with. [00:48] ailo, Ok now both qjackctl and gladish have gone blank on me... not what I want to throw at a new user :/ [00:48] When they crash, it's a bit of a hazzle killing them [00:49] I killall button could have be set to kill a list of predermined applications, active or not [00:49] I'm getting a bit tired evidently [00:52] I wouldn't mind replacing qjackctl with something else. Preferably something that starts out being a kind of hybrid PA/Jack controller, like a simple volume control with a menu (like the current PA volume control) with a patch bay. But with all the config options hidden deeper in options [00:53] Well, PA and jack would still need separate patchbays [00:53] ailo, qjackctl has no problems at higher latencys [00:54] Try it at -p 512 [00:54] I've been using 1024 [00:54] 1024 was ok too for me. Maybe I didn't cycle it enough [00:54] But, there's a problem with this machine, using threadirqs. At least I get xruns easily because of it [00:55] I was testing at -p 64 before [00:56] I need to get some sleep. bb in a few hours [00:57] k bye [10:15] I see the need for some kind of general troubleshooting wiki page [10:15] So, I started one [10:16] We also need to explain the difference between jackd1, jackd2 and jackdbus, as well as alsa and jack midi [10:16] All of these things should probably end up in the main web site later, I think [10:17] So, I've just begun populating this page a bit https://help.ubuntu.com/community/UbuntuStudio/TroubleShooting [10:18] If we add more stuff, we just categorize it under things like "jack", "midi" or whatever [10:42] len-dt: Have you had problems with previous kernels? [10:43] I put together a short guide on how to build the natty, or the oneiric kernel [10:43] https://help.ubuntu.com/community/BuildOldLowlatency [10:45] Someone was having some serious raid problems, so he needed to revert back to an older kernel [10:45] I believe 2.6.38 will outperform any 3.2 kernel [10:45] Those kernels were tight for audio [13:09] ailo, I only really started testing at 11.10. Also I have a simpler setup than most. [13:38] ailo, performance doesn't seem to be an issue with our current kernel. I still run out of memory before cpu/kernel time. [13:57] ailo, those two trouble shooting tips covers a lot of questions we get. === shnatsel is now known as SergeLion [14:08] ailo, weird thing happened just now. started the xfce4-mixer... didn't seem to start... 5 minutes later it showed up. === SergeLion is now known as shnatsel === shnatsel is now known as SergeLion === SergeLion is now known as shnatsel [15:18] len-dt: I did a lot of testing with 2.6.37-39 [15:18] They were better performing [15:19] len-dt: But, what I was curious about was if maybe your networking problems might diminish with an older kernel [15:24] Just for the sake of interest, I'll try the PA jack bridge for this day, using -p 32 to see the difference [15:24] I'm betting I will have few, if any xruns at all [15:52] ailo, actually, the brudge gives me no problems if the internal IF is turned off. [15:53] len-dt: Well, it does for me [15:53] With the older kernel [15:53] I mean, with the newer one [15:54] It doesn't handle really low latencies [15:55] ailo, I should try my USB IF on this machine to see if it does better than -p 64 that it does on my netbook. [16:13] len-dt: With this older kernel, I do get an occasional xrun with the jack bridge at -p 32, but so far it seems only when I start something, like a new instance of flash player. With the newer kernel, I'd have about the same performance at -p 64, but with more xruns, and more random [16:13] len-dt: Please do try the older kernel, just for reference [16:13] I think it would be interesting to see what happens [16:26] which PPA? [16:27] * len-dt is still a newby when it comes to setting up odd PPAs and stuff === shnatsel is now known as SergeLion [16:35] len-dt: No PPA. The guide is for building your own kernel [16:35] Pretty straight forward. The only part which may need some considering is when you run the command "make oldconfig" [16:36] The make script creates a new config, based on the old once. There are always diffs between kernel versions, so the configs never match [16:36] So, you need to answer y/n or m for a lot of config options [16:37] As I explain in the guide, you probably need to say no to cgroups in the beginning, and it's always good to say no to debug stuff (to reduce latency) [16:37] For the most part, I didn't read the configs. Just kept pushing Enter (to get the default config) [16:38] I will add another guide, using a different, more simple way of creating the configs [16:38] I'll probably want to add some kernels to a PPA too later [16:49] There's something funny going on with the PA bridge [16:49] I started getting xruns, but only after a good while of using a PA application [16:49] Once I stopped the app, no xruns [16:49] The PA-bridge on the whole time [16:50] Took about 30 min before I started getting even one xrun [16:50] A flash video that is about 1h long [16:52] Anyway, It'll reappear later, when I start doing more systematic testing [16:59] ailo, I was going to ask why run a flash video through PA-jack, but I guess firewire stuff still needs that. [17:00] len-dt: I'm testint the bridge. That is the only reason right now [17:01] len-dt: Also, why would you not want to do that? If you're using jack and want to watch a flash video at the same time [17:02] You can answer, well, you'll mess up your recording cause the bridge causes xruns. But, maybe I'm just practicing guitar playing to a youtube video [17:02] There's no way of guessing what the user will use applications for [17:02] The only thing that matters is knowing what works and what does not [17:03] And try to fix the stuff that doesn't [17:04] makes sense. [17:40] ailo, just install qjackctl 0.3.9 Wiil test. (thanks falktx ) [17:43] ailo, jackdbus bug still shows up (no surprise) [18:00] len-dt: Does qjackctl kill jackdbus when that happens? [18:03] Let me check [18:08] jack_control status returns "stopped" [18:08] So jack stops but does not exit. [18:08] Can you restart it? [18:11] only if I restart qjackctl [18:11] That's at least some progress [18:18] ailo, if I wait till qjackctl is finished as much as it can and kill jack and restart it using jack_control, I don't have to restart qjackctl. [18:32] len-dt: I'm more concerned about the novice user perspective. If it stops working, and restarting qjackctl is enough, then I don't think the bug is causing too much problems [18:32] jacks dbus stuff is flaky [18:33] Yeah. It's too bad [18:33] I gotta go. bb later [18:33] bye === SergeLion is now known as shnatsel === shnatsel is now known as SergeLion [21:18] The thing about PA I think is that it syncs with the bridge. Not with jack [21:18] I'm just guessing, since I don't really know [21:18] That is how I would have done it anyway [21:19] PA could have a larger latency to the bridge than jack [21:19] The bridge itself is a jack app, but PA never becomes one [21:20] Well, a hybrid [21:21] At least I'm pretty sure that PA never runs at the same low latencies that jack does [22:13] ailo, where is jack setting the latency? Is it internal to jack? or is it an ALSA setting? [22:14] That is, I am sure that Jack does not talk to alsa (and therefore the port) once per sample. [22:15] len-dt: I don't think alsa is a server at all when used with jack, or with PA. PA is a server, jack is a server, alsa is the driver code they use [22:15] That's my picture of it anyway [22:16] So, jack sets its' own latency, as does PA [22:16] Ok, so doews jack feed audio directly to the hardware? or through ALSA? [22:17] The device is generated by ALSA. That is there is no audio device before alsa runs. [22:18] Alsa is the interface, that jack controls [22:18] The device drivers are a part of alsa. So jack sends data to the device through the device driver [22:19] I feel kind of stupid trying to make sense of this though. Some day I will find out :P [22:20] in any case there is no reason that the bridge has to run at jack latency, at least not the whole thing. There has to be a small engine that does, but there could be a biggere buffer behind it that adds as much latency to the signal to make PA happy. [22:21] I don't think that happens though. [22:23] * len-dt fingers fumble worse than his tongue [22:45] ailo, I think the buffer is in the alsa hardware driver. Jack just sets the size. That would mean PA has to set the size for its use too. I don't see why it would have to be global though [23:06] ailo, on the other hand, it would be intuitive that if the user set jack to low latency that they would "want" anything on the other side of a PA-jack bridge to also be low latency... I'm talking from a PA developers view. [23:09] bleh scott. [23:09] knome: You miss him? [23:09] ailo, yeah, a lot [23:09] He's kind of VIP these days [23:09] around where? :P [23:10] I mean like a special guest, that drops by every now and then :) [23:10] heh. :) [23:10] He was talking about having a new computer set up soon [23:11] i knew he wasn't important, but not important enough to be here all the time ;) [23:12] He probably deserves some time off too [23:12] ;) [23:13] len-dt: I think it would be nice to be able to control PA latency, and maybe it's possible. I only had a quick look at PA configs just a couple of days ago [23:13] In a way, it's a good thing that you never feel the need to look at configs [23:13] Should be like that with everything [23:13] Just push a button and it's rock'n'roll [23:15] Phew, going to ride a bicycle 120km tomorrow. I'm worried about my behind getting sore [23:16] Better get some sleep