[00:34] <Tode_I> I'm loving Carla 2.0, lovin it
[00:58] <wonko> I've never used previous Carla, but I'll echo that, it's really nice
[01:16] <wonko> Ok, so I recorded some audio from the mic into Ardour but I don't know how to get it to play back? I click play but no sound comes out
[01:27] <wonko> Oh!
[01:27] <wonko> Nevermind. I see. Hmm.
[01:54] <Tode_I> So I'm assembling patches to play keys on some cover tunes, among them Rebel Yell. What's the best monosynth plugin to use to get that portamento thing that plays right after he sings "came dancing to my door"?
[02:03] <wonko> Hmm, If I add the Calf Analyzer to the Carla Rack and click on the GUI button it crashes Carla. :(
[02:04] <wonko> Calf Gate doesn't crash Carla
[02:08] <wonko> Neither do Compressor or Limiter
[02:08] <wonko> just Analyzer
[08:31] <AppAraat> hello, I'm looking at using Ubuntu Studio as main install on my (X220) laptop. Daily I'm using Chromium, Firefox, qBittorrent and virt-manager. In terms of media production, my only tool of choice is Bitwig Studio.
[08:32] <AppAraat> However, I want to use i3wm instead of the default DE. Would my use case be something you'd recommend against?
[08:32] <AppAraat> as in: Does Ubuntu Studio fit my use case?
[08:34] <AppAraat> oh, I might also run a few Steam games from time to time too.
[15:21] <wonko> Sep 20 10:06:30 deepthought systemd-udevd[1037]: Spawned process '/usr/bin/systemd-run /usr/sbin/udev-rtirq a /devices/pci0000:80/0000:80:03.0/0000:82:00.1/sound/card0' [1696] is taking longer than 59s to complete
[15:21] <wonko> OvenWerks: So I don't even think that's working
[15:27] <wonko> sudo /usr/sbin/udev-rtirq a /devices/pci0000:80/0000:80:03.0/0000:82:00.1/sound/card0
[15:27] <wonko> that responds immediately though
[15:47] <wonko> Oh, that's not even the right device
[15:47] <wonko> That's one of the gtx outputs
[15:59] <wonko> Ok, I found the right device
[16:01] <wonko> I ran udev-rtirq manually but unlike the gtx device I don't see it as being set to RT priority 95 in the output of /etc/init.d/rtirq status
[16:21] <OvenWerks> AppAraat: you might be better to set up you computer first with the de of choice and install the audio parts on top using ubuntustudio installer.
[16:24] <OvenWerks> AppAraat: however, I if there is no ubuntu flavour with your chosen DE already, you are welcome to install the studio ISO first and add the de on top. xfce does not take much room on the drive and should not interfere with things
[16:25] <OvenWerks> AppAraat: my son runs steam stuff on a studio install with out problems.
[16:25] <OvenWerks> wonko: I also had no luck with udev-rtirq
[16:26] <OvenWerks> wonko: even after disabling xhci on my box
[16:26] <OvenWerks> I think it only worked for the author for that one kernel.
[16:28] <OvenWerks> wonko: I have been looking at the information udev and dbus give on usb audio device when it is plugged in or a boot happens. I have not found the information needed to do what needs to be done.
[16:29] <OvenWerks> wonko: I think the whole USB setup was never designed for lowlatency anything :P
[16:32] <wonko> It really wasn't, no. 😁
[16:32] <OvenWerks> wonko: there are a number of problems
[16:33] <OvenWerks> wonko: first, in order to change the priority of an irq for a process we need the iterrupt server's PID
[16:34] <OvenWerks> normally one might take the name and ps ax |grep <name>
[16:35] <OvenWerks> however, in this case with 8 xhci processes running, which one is it?
[16:37] <OvenWerks> In your case with the pcie usb card we at least know it is usb5... so we can look up the pci card using lspci -v
[16:38] <wonko> So if we still the rtprio for the card would that include the USB devices?
[16:38] <OvenWerks> That does give an irq... but That is the physical IRQ and the pcie card throws that away and uses a virtual irq anyway so that would be the wrong one
[16:38] <wonko> Set, not still
[16:38] <wonko> Hmm
[16:40] <OvenWerks> AS an example, lspci on my machine shows that the ehci for usb1 is irq17 but cat /proc/interrupts shows it as irq/20-ehci_hcd
[16:43] <OvenWerks> wonko: so my missing link is either A) the real irq or B) the PID of the irq driver
[16:43] <OvenWerks> really both end up being the same info.
[16:49] <OvenWerks> wonko: to make things harder, we like harder right, I think it is possible that the virtual irq the device uses may change at reboot
[16:50] <OvenWerks> I haven't seen that happen so I don't know how likely that is
[16:57] <OvenWerks> So what we do know: which usb bus the device is using, the pid of each xhci irq server
[17:11] <wonko> Harder is good, yes. :-D
[17:12] <wonko> Can we somehow map those two things to intersect and give us the answer we need?
[18:19] <OvenWerks> wonko: That is what I have been trying to do. The rtirq script just raises all the usb buses :P
[18:21] <OvenWerks> and it does so at random with the result of most often the mouse has a higher priority than all the audio hw and software ...
[18:22] <OvenWerks> even in the case like your's with a separate pcie usb card. (BTW, a pcie usb2 only card would probably work better)
[18:23] <OvenWerks> ls
[18:23] <OvenWerks> focus does not follow mind still :(
[18:47] <wonko> OvenWerks: That's ok, I've been typing kubectl commands into another irc server all day now.
[18:48] <wonko> Now I'm curious though about that udev-rtirq script
[18:49] <wonko> Why does it hang trying to set the priority of the GTX1080 audio at boot when udev runs but not when I run it manually?
[18:50] <OvenWerks> wonko: could be the order devices are connected. Could be the cpu is busy at boot and it takes the usb audio device a bit longer to connect.
[18:50] <wonko> but it's not the usb audio it's hanging on, it's the nvidia one
[18:50] <OvenWerks> lots of differences...
[18:50] <OvenWerks> that figures
[18:51] <OvenWerks> Nice big code blob that no-one knows what is there
[18:51] <wonko> which then causes udev-settle to fail
[18:51] <wonko> which chain reactions because a ton of stuff depends on that
[18:51] <wonko> I found that because my zpool wasn't importing
[19:05] <wonko> so, this might be an issue:
[19:05] <wonko> wonko@deepthought:~$ echo $pid
[19:05] <wonko> 546 547 548\
[19:05] <wonko> the script finds 3 PIDs
[19:05] <wonko> and I have a feeling that chrt doesn't like that (and/or is changing the wrong one
[19:06] <wonko> wonko@deepthought:~$ echo $thread
[19:06] <wonko> irq/35-PCIe PME irq/35-aerdrv irq/35-s-aerdrv
[19:07] <wonko> wonko@deepthought:~$ /etc/init.d/rtirq status | grep irq/35
[19:07] <wonko>   546 FF      50   -  90  0.0 S    irq/35-PCIe PME	
[19:07] <wonko>   547 FF      50   -  90  0.0 S    irq/35-aerdrv	
[19:07] <wonko>   548 FF      49   -  89  0.0 S    irq/35-s-aerdrv	
[19:09] <OvenWerks> wonko: posibly changing the wrong one. changing one irq server with touching the others is supposed to work.
[19:10] <OvenWerks> wonko: but the real solution is to not use an irq that something else uses
[19:10] <wonko> https://paste.ubuntu.com/p/Fn6m7fX4KC/
[19:10] <wonko> for your reference
[19:10] <wonko> so it's getting the IRQ for thw PCI bridge
[19:10] <wonko> not the USB card
[19:10] <wonko> or the sound device
[19:10] <wonko> so his logic may be flawed
[19:11] <wonko> Also, this line probably isn't working as intended: chrt -f -p $priority $pid
[19:11] <OvenWerks> Also the IRQ in that file is the HW irq not the virtual irq that the device ends up using
[19:11] <wonko> the man page for chrt says [pid]
[19:11] <wonko> so it's looking for a single pid
[19:12] <wonko> and it's being handed three
[19:12] <OvenWerks> That line looks right
[19:12] <wonko> which I guess it's just ignoring the last two
[19:12] <OvenWerks> ya would have to do one at a time.
[19:12] <wonko> that expands to: chrt -f -p 95 546 547 548
[19:12] <wonko> which I'm guessing (don't know for sure) doesn't work
[19:12] <wonko> that being said, as you can see, it's set *none* of them to 95, so it's definitely failing
[19:13] <OvenWerks> none of those is that right one anyway.
[19:13] <wonko> so yeah, we need to get the real IRQ
[19:13] <wonko> yeah
[19:14] <OvenWerks> well that is a real irq... the card just doesn't bother to use it :)
[19:14] <wonko> wonko@deepthought:~$ /etc/init.d/rtirq status | egrep -v "ens1|enp4s0f|megasa" | pastebinit
[19:15] <wonko> http://paste.ubuntu.com/p/hQtbcqcF9n/
[19:15] <wonko> that's the list of stuff I know for a fact it has to be from. :)
[19:15] <OvenWerks> notice that none of the ehci/xhci IRQs is 35
[19:16] <OvenWerks> The real question is which of those ehci/xhci shown is the one you want?
[19:17] <wonko> yeah, 35 is the pci bridge
[19:18] <OvenWerks> in rtirq staus I think the name of the command/process is trunkated
[19:18] <wonko> https://linuxmusicians.com/viewtopic.php?t=911
[19:18] <wonko> thoughts on this?
[19:20] <OvenWerks> maybe Thats old... it used to work just setting usb1 for example. xhci doesn't always have the :usb? tag anymore
[19:20] <OvenWerks> ehci does
[19:20] <OvenWerks> you might try black listing the xhci module
[19:22] <wonko>   iSerial                 1 0000:81:00.0
[19:22] <wonko> which of course I already knew. :)
[19:26] <wonko> ok, so the IRQ of the USB controller is 24
[19:27] <wonko> wonko@deepthought:/sys/devices/pci0000:80/0000:80:02.0/0000:81:00.0$ /etc/init.d/rtirq status | grep irq/24
[19:27] <wonko> wonko@deepthought:/sys/devices/pci0000:80/0000:80:02.0/0000:81:00.0$
[19:27] <wonko> which......... doesn't exist. :)
[19:29] <OvenWerks> It is easy to find out which usb bus the device is on. it is not so easy to find out which PID services the irq for that bus
[19:31] <OvenWerks> I am (along with other things) trying to search through /proc/<pid>/ to see if I can find out which bus that PID works. The problem is that we know everything a level or two down... just not the top.
[21:18] <AppAraat> OvenWerks: thanks, I thought maybe the lowlatency / RT kernel might interfere with some day-to-day stuff (like VMs). I'll try out Ubuntu Studio in the VM right now.
[21:19] <OvenWerks> The lowlatency kernel is pretty much the same as the generic kernel with just one or two parameters set differently
[21:22] <AppAraat> I believe I tweaked some parameters on my current kernel (Ubuntu 16.04) but still couldn't achieve lowlatency / RT, though I think other factors are likely at play here (I haven't setup IRQs for example, but I assume that Ubuntu Studio has set those things up correctly)
[21:25] <AppAraat> I think my WLAN interface is a big culprit for some of the major xruns.
[21:27] <AppAraat> do all of you use Ubuntu Studio as a daily driver?
[21:27] <OvenWerks> AppAraat: that could well be. Some WIFI drivers have large atomic code bits in them. Also know that some wifi chips have more than one driver that will work with them and sometimes the worst one is the one that picked up.
[21:28] <OvenWerks> I use Studio for everything...
[21:29] <OvenWerks> but then, as with everyone, I have a limited set of workflows in my life.
[21:29] <AppAraat> oh, that's good to know, thanks. I'm thinking of flashing coreboot on my X220T and then getting one of those Atheros cards (have an Intel one currently)
[21:30] <OvenWerks> Caertainly there is browsing, audio kinds of stuff. I do some dev work both on Studio and Ardour.
[21:30] <AppAraat> yeah I am a limited workflow kind of guy too. I only need Bitwig Studio and for it to interact with external hardware (either via MIDI or CV)
[21:30] <AppAraat> in fact, I'm looking at only using ALSA if that's even possible (since I don't know why I'd need JACK, let alone PA)
[21:32] <OvenWerks> you only need PA for skype, firefox and the like.
[21:33] <AppAraat> I'm ok with not using PA for FF (and luckily I don't use Skype)
[21:33] <AppAraat> usually for Youtube I just pass it to mpv, which uses youtube-dl to play videos.
[21:33] <OvenWerks> That should work.
[21:40] <AppAraat> interesting, so PA is present on the system and running at boot (at least in the live environment). I'm curious how the distro maintainers made it work along with the goal of having a pro audio setup, since it has given me nothing but headaches on my current system.
[22:04] <AppAraat> super, apparently one has to do some acrobatics in order to make audio work in KVM: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/591489/