| OvenWerks | I would point out that rtirq does not change the priority of irqs, It changes the priority of the second half of the irq drivers which are driver specific rather than irq specific. | 00:01 |
|---|---|---|
| JackWinter1 | OvenWerks: yes ofcourse, its just easier saying it like that | 18:16 |
| JackWinter1 | or should i revisit the documentation of my utility? maybe i've taken the same liberty there :) | 18:17 |
| OvenWerks | JackWinter1: the difference is important in the case where a device shares irq (probably 16) with other things. rtirq gives each device on that irq a different priority. | 19:36 |
| OvenWerks | JackWinter1: unfortuately it tends to still raise the priority of devices not listed that _should_ be at 50. | 19:37 |
| JackWinter1 | yes | 19:39 |
| OvenWerks | JackWinter1: A thought I have is to present a warning screen or at least an info screen that details what devices any audio device we are using shares irqs | 19:39 |
| JackWinter1 | i'm still not shure what is the best way of handling that. but once it's in the thread the top half is done, and the threads are preemptable | 19:40 |
| JackWinter1 | so for our purposes the other devices using the same irq are probably not important | 19:41 |
| OvenWerks | it depends on if we are using only one audio device or more | 19:41 |
| OvenWerks | For example, midi devices are always separate | 19:41 |
| OvenWerks | even in a combo-device that has both audio and midi | 19:42 |
| JackWinter1 | several soundcards sharing interrupts, that's an intriguing scenario | 19:42 |
| OvenWerks | that is not quite what I meant :) | 19:42 |
| JackWinter1 | i know :) | 19:42 |
| JackWinter1 | my babyface has only one interrupt | 19:43 |
| OvenWerks | I am thinking an audio card that shres with a mouse and another. if the one that shares with a mouse is at 95 and the mouse therefore ends up at 90 then the second audio card might be at 85 | 19:43 |
| JackWinter1 | you are talking about usb? | 19:44 |
| OvenWerks | usb, pci, fw whatever. | 19:44 |
| OvenWerks | again this is a problem with rtirq, not your sw... (which I have yet to test) | 19:45 |
| JackWinter1 | if 2 devices share the same interrupt say soundcard and an usb root hub, i'd be inclined to change only the thread that services the soundcard | 19:46 |
| OvenWerks | right | 19:46 |
| OvenWerks | rtirq is old stuff from when pci audio cards were king | 19:46 |
| OvenWerks | It works great for that | 19:47 |
| JackWinter1 | it's part of the reason i wrote this, as i don't like how rtirq does it, and because it doesn't work for hotplugging cards | 19:47 |
| JackWinter1 | as it is right now, it only cares about soundcards, nothing else | 19:47 |
| OvenWerks | one of the troubles I have with rtirq is raising the priority for my NIC (to play with AVB/aes67), rtirq runs before my NIC shows up. | 19:49 |
| JackWinter1 | you could run rtirq once again manually? | 19:50 |
| JackWinter1 | i suppose this utility could be adapted to deal with other things too | 19:51 |
| OvenWerks | Yes, and I do, but rtirq does not reorder priorities, it just jams the NIC where it can. | 19:51 |
| JackWinter1 | but then it starts getting complicated ;) | 19:51 |
| JackWinter1 | imo, you ought to prune the config to the minimum... | 19:51 |
| JackWinter1 | i never saw a reason for many usb interrupts to get a higher priority than nic/hdd/etc | 19:52 |
| OvenWerks | I don't know the NIC handling code that well, but the i210 does a lot of processing on it's own anyway. | 19:52 |
| JackWinter1 | and the infamous rtc... on my systems it fires exactly once on boot | 19:52 |
| OvenWerks | normally a NIC should not be raised at all | 19:53 |
| JackWinter1 | maybe in your case it's useful, i don't know | 19:53 |
| OvenWerks | but to use with avb or aev67 we want to use the timer on the NIC to syn audio clock | 19:53 |
| JackWinter1 | there is also the old chrt -f -p 98 `pgrep nameofthread` | 19:54 |
| JackWinter1 | you can run that from a script starting your daw or something like that | 19:54 |
| OvenWerks | in these cases the NIC _is_ the audio device. | 19:56 |
| JackWinter1 | so udev sees it like an audio device or a network card? | 19:56 |
| OvenWerks | NIC | 19:56 |
| OvenWerks | But there is so much stuff to set up that the driver should be able to do it's own prioritizing I guess | 19:57 |
| JackWinter1 | actually how well does that work? i'm considering looking into avb/aes67 for my next card | 19:58 |
| JackWinter1 | have no idea if it works at all on linux though | 19:58 |
| JackWinter1 | think i've seen some posts from people experimenting, maybe you one of them | 19:58 |
| OvenWerks | I should look at the avb code. | 20:01 |
| OvenWerks | there is no avb/aes67 driver that could be called finished and easy to use | 20:02 |
| OvenWerks | avb can get sound from jack to jack for sure. | 20:02 |
| OvenWerks | I would think it should be possible to go from another end point to/from jack as well | 20:03 |
| OvenWerks | but everything is manual setup | 20:03 |
| OvenWerks | My thought on either avb or aes67 is to use the timer from the NIC (ptp server) to time a jack dummer back end and then connect remote audio as jack client | 20:05 |
| OvenWerks | s/dummer/dummy/ | 20:05 |
| JackWinter1 | ah i see, i'm more interested in connecting a soundcard to my linux machine | 20:06 |
| OvenWerks | the jack client should not need SRC as it derives it's sync from the same ptp server | 20:06 |
| OvenWerks | yes this would connect an avb sound card to linux... through jack | 20:07 |
| OvenWerks | in my case my linux machine sees jack as my audio card anyway. | 20:07 |
| OvenWerks | really in both cases, the stuff to get audio from one place to another is all there, it is just missing the glue to discover and connect. | 20:09 |
| * OvenWerks is gone for a few minutes | 20:09 | |
| OvenWerks | JackWinter1: basically, all the avb audio IFs I know about also connect via USB. For aes67, it is dante units run in aes67 mode, so less useful. | 20:42 |
| OvenWerks | I think the fire has gone out of the Audio device support in Linux people. Basically anything that works for mac works for Linux with the USB drivers so why work on anything more? There is not even BT audio any more for alsa... of course BT through pulse works and BT is about as reliable as pulse, so using PA as an output to bt is probably acceptable :P | 20:45 |
| JackWinter1 | heh, and latency sucks with usb compared to on windows :S | 20:52 |
| OvenWerks | ouch | 20:53 |
| JackWinter1 | maybe you are right. we'll see what happens in the future. i suppose we ought to be grateful that there is class 2.0 audio in any case, otherwise what would many users use | 20:53 |
| OvenWerks | usb mics should die... | 20:53 |
| JackWinter1 | though i ran into a guy that hacked the snd-usb-audio driver so that you can modprobe some extra parameters, made the latency overhead very little even at big buffer sizes, so it appears even class 2.0 could work much better on linux :S | 20:55 |
| OvenWerks | but on the other hand, -controls deals with them nicely now :) | 20:55 |
| JackWinter1 | https://aur.archlinux.org/packages/snd-usb-audio-lowlatency-dkms/ if you are interested | 20:55 |
| OvenWerks | I can do 16/2 at 48000 with no xruns over night | 20:56 |
| JackWinter1 | i still have to test that patch more, but it makes my rme baby face work nearly as good latency wise on linux as on windows | 20:56 |
| OvenWerks | (with my old PCI delta 66) | 20:56 |
| OvenWerks | usb should be able to do 16/3, but I think 32/2 is as good as most people can get. | 20:57 |
| JackWinter1 | that's not really a useful test, the question is what happens when you throw dsp load on it, and load down the machine otherwise... that's when xruns start turning up | 20:57 |
| JackWinter1 | i'd be happy with 64-128/2 with low additional latency :) | 20:58 |
| JackWinter1 | brb, i've gotta test the kernel i reconfigured :) | 20:59 |
| JackWinter1 | beh, i copied .config to . and not config, so now i can build it again :S | 21:04 |
| JackWinter1 | so basically i messed it up and can build it all over again :) | 21:05 |
| OvenWerks | :P | 21:11 |
| OvenWerks | There seems to be a "it's as good as it gets" attitude in linux audio. Xruns? increase latency... rather than finding out why. | 21:12 |
| JackWinter1 | yes, i suppose that snd-usb-audio caters to the worst case so sucks for all cards... | 21:20 |
| JackWinter1 | but i suppose we are really a small minority trying to produce music on linux... | 21:21 |
| OvenWerks | I don't think that is the whole story, I think there is a lot of variability in MB circuitry as well. | 21:22 |
| JackWinter1 | i have no idea about the usb protocol, but the above patch really works miracles with the right values for my babyface, latency close to that on windows.. | 21:23 |
| OvenWerks | many people use lap tops for audio work and so it is hard to say use a dedicated PCIe SUB card as an example as compared to FW days when people very definately would get a fw card that was known to work well/best | 21:23 |
| JackWinter1 | the the most important being max_packs_hs set to 1 | 21:23 |
| OvenWerks | :P my fingers at work s/SUB/USB/ | 21:25 |
| OvenWerks | One just has to look at the big users of USB to understand how drivers are set up... how fast can I transfer my pictures? | 21:28 |
| OvenWerks | how fast can I back up my drive to USB, etc. It is all about max throughput, latency should be at least lower than 30ms... That attitude does not help audio at all. | 21:30 |
| JackWinter1 | no, but surely the snd-usb-audio driver is for audio :_) | 21:49 |
| JackWinter1 | too bad that it seems not to be working optimally | 21:49 |
| OvenWerks | I was talking about the underlying USB code. | 21:49 |
| JackWinter1 | well with the patch i got quite decent performance out of it | 21:50 |
| OvenWerks | good stuff. | 21:50 |
| JackWinter1 | didn't write down the values, but hang on let me find a post | 21:50 |
| JackWinter1 | check out the improvement: https://forum.cockos.com/showpost.php?p=2021776&postcount=17 | 21:52 |
| JackWinter1 | i saw similar results | 21:53 |
| JackWinter1 | iirc (lol it was a few days ago), i can write the new values in the sys file system and disable/enable the usb device in sysfs too, and then it just works better, but have no idea what it might break on other machines or usb soundcards | 21:55 |
| OvenWerks | That is always the problem | 21:55 |
| JackWinter1 | well i'm egoistical enough to be happy to solve my own problems :) | 22:05 |
| OvenWerks | I have some of that, but I like to help others too... In their case "good enough" is less good than for me. | 22:06 |
| JackWinter1 | time to see if this kernel helps anything ;) | 22:11 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!