| === dax is now known as housecat | ||
| StevenJayCohen | OvenWerks: Eickmeyer You'll like this. A couple of narrators asked that we change the theme AWAY from Materia because they'd like something where the widgets in the UI have more definition. Since I'm not a fan of the Yaru color pallette, I enabled Adwaita. They liked it. So, I'm playing with that now on my laptop -- still using Papirus icons though. | 11:41 |
|---|---|---|
| StevenJayCohen | Adwaita with Ubuntu Purple would be perfect IMO | 11:41 |
| StevenJayCohen | I took off my glasses (which I rarely do when I'm using my computer) and worked that way for a while. Once eye strain started to set in, I was appreciating borders on the buttons | 11:43 |
| OvenWerks | StevenJayCohen: thats what options are for :) | 14:35 |
| OvenWerks | StevenJayCohen: I find it interesting the difference between graphic designers and people who use their computer to get work done. | 14:38 |
| OvenWerks | between people who use their computer to entertain themselves and those who expect to get maximum productivity | 14:39 |
| OvenWerks | Win95, CDE, etc. were made for business use, for productivity. Almost everything since has been more and more focused at the entertainment use | 14:41 |
| OvenWerks | Eickmeyer[m]: sorry to bug you ... re: https://bugs.launchpad.net/ubuntu/+source/ubuntustudio-controls/+bug/1872187 | 15:11 |
| ubottu | Launchpad bug 1872187 in ubuntustudio-controls (Ubuntu) "ubuntustudio-controls crashed with IndexError in refresh_dropdowns(): list index out of range" [Medium,Incomplete] | 15:11 |
| OvenWerks | This does look like a real bug | 15:11 |
| Eickmeyer | It does, but not for Controls. I'm going to add the kerenel to it since it appears to be hardware related. I have tested extensively with my Nvidia hardware, and no issues. So the issue is very likely the hardware. | 15:12 |
| OvenWerks | My question is: where should I fix it? In ubuntustudio-controls or studio-controls | 15:12 |
| Eickmeyer | You have nothing to fix. | 15:13 |
| Eickmeyer | OvenWerks: From what I can ascertain, it's a kernel problem. | 15:15 |
| OvenWerks | I thihnk controls should check for a device that has no description. That is I should check that it exists before reading it. | 15:15 |
| Eickmeyer | Oh, I definitely agree. So, is this a device that has no description? | 15:15 |
| OvenWerks | it appears the file has Name: "" | 15:15 |
| OvenWerks | I catch the "Name" part and try to read from : to the end of the line which does not exist | 15:16 |
| OvenWerks | So, if the kernel has a bug or not, -controls also has a bug :) | 15:17 |
| OvenWerks | The question still remains if it should be fixed in ubuntustudio-controls or studio-controls | 15:17 |
| OvenWerks | (the first option means both of course) | 15:18 |
| Eickmeyer | If we want to do a simple backport, then studio-controls. If we want to fix this as an SRU (which should be the proper procedure for something like this), ubuntustudio-controls. I'm leaning toward ubuntustudio-controls. | 15:20 |
| StevenJayCohen | I've been trying to figure out if I've got a studio bug or a bug in my DAW. After recording for at least 30 minutes, the ability to record suddenly stops. Stopping and restarting recording fixes it. And, I can't find much of anything in logs. | 15:24 |
| OvenWerks | StevenJayCohen: what file format are you recoring to? | 15:25 |
| StevenJayCohen | I'm collecting timestamps when it occurs during this session and will look back through logs after the talent leaves. | 15:25 |
| StevenJayCohen | WAV 24bit | 15:25 |
| OvenWerks | StevenJayCohen: use Bwav | 15:26 |
| OvenWerks | Normal wav does have a file length restriction | 15:26 |
| StevenJayCohen | Will check that for the next session after this one. Thanks for the tip! | 15:26 |
| OvenWerks | bwav does not. | 15:26 |
| OvenWerks | bwav also saves in 32bit float instead of 24 bit int | 15:27 |
| StevenJayCohen | OvenWerks: It isn't a continuous record of 30+ minutes. It's files that start and overlap each other covering mistakes. | 15:27 |
| StevenJayCohen | Talent flubs a work every 3-15 minutes. | 15:27 |
| StevenJayCohen | So, each time a new take on the track where we go back to the top of a paragraph | 15:28 |
| OvenWerks | Eickmeyer: I am fixing Studio-controls, but it is no difficulty to drop the same fix in us-c | 15:28 |
| OvenWerks | Which DAW? What if the number of open files limit? | 15:28 |
| Eickmeyer | OvenWerks: Ack. We can switch the bug into an SRU. | 15:28 |
| OvenWerks | StevenJayCohen: ^ | 15:28 |
| StevenJayCohen | OvenWerks: Reaper, shouldn't be an issue. Files from other chapters are all offline. So, shouldn't be approaching any limit and not seeing high memory usage | 15:31 |
| StevenJayCohen | Reaper for Linux | 15:31 |
| StevenJayCohen | http://reaper.fm | 15:31 |
| * OvenWerks doesn't know reaper at all aside from hearing good thnigs of it. | 15:32 | |
| StevenJayCohen | Free to use unlicensed if you want to try it out | 15:32 |
| StevenJayCohen | talent back from break, back to recording | 15:32 |
| OvenWerks | StevenJayCohen: if I ever have time... | 15:33 |
| StevenJayCohen | Session ended and I was looking through my log files. Could this cause the issue that I was describing? https://askubuntu.com/questions/1167586/memory-leak-in-tracker-extract | 17:12 |
| StevenJayCohen | I just looked up tracker. Could it be that the mass creation of WAV files during a project might be at issue? Is there a way that I can prevent it working in a particular folder? | 17:14 |
| OvenWerks | you would need to investigate further. | 17:16 |
| StevenJayCohen | It would make sense if this was it, so maybe I just need to read up on indexing and tell it to never index the contents of the project folders | 17:17 |
| OvenWerks | top or htop could be useful | 17:17 |
| StevenJayCohen | good idea, I'll try that. | 17:17 |
| OvenWerks | file writing does use memory as cache but application memory use always has priority and if there is not enough memory for caching drive blocks it will direct write | 17:19 |
| OvenWerks | (to a point anyway) | 17:19 |
| OvenWerks | audio applications _should_ be using memlock so as to never be swaped out | 17:20 |
| StevenJayCohen | Right, that did occur to me. It's the only lead I have so far, and it may be a red herring | 17:52 |
| OvenWerks | Eickmeyer: upload to us-c. Maybe build in dailies first and ask the reporter to see if this fixes their problem. | 19:07 |
| Eickmeyer | OvenWerks: Building. If it works, we'll have to make it an SRU. | 19:09 |
| OvenWerks | works ok here... but then i never had a problem in the first place | 19:18 |
| OvenWerks | studio-controls als updated | 19:18 |
| OvenWerks | Eickmeyer: in light of switching to the k desktop, is anything I put in controls for tablets going to add to that? | 19:19 |
| Eickmeyer | Cool. I updated the bug report. This person seems responsive, so we should know soon. | 19:20 |
| Eickmeyer | Going to Plasma, I think the stuff for tablets will just make an even more refined experience, but the person to ask about that would be eylul[m]. | 19:20 |
| Eickmeyer | OvenWerks: Could you do a write-up about the firewire stuff that I can use for the blog? It seems this lack of firewire "support" has angered people and raised more than a fair share of eyebrows. So much so that I had to ban someone from the ML. | 19:25 |
| studiobot | <teward001> > Firewire is a very old and obsolete hardware connector. Over time, it has become so old and obsolete that we cannot continue to support it. Therefore, 20.04 does not support Firewire devices. This was a hard decision, however we cannot continue to support extremely obsolete hardware and connectors. | 19:30 |
| studiobot | <teward001> quick little blurb from my butt 😜 | 19:30 |
| OvenWerks | @teward001 the problem seems to be with the word "Support" | 19:33 |
| OvenWerks | The kernel and jack still support firewire. We as people do not have the knowledge to offer support | 19:34 |
| OvenWerks | For many people the new alsa FW modules just work. | 19:34 |
| * OvenWerks uses an old PCI based audio card cause it is still much better than any USB audio device out there.... and it is not top of the line for sure. It is the same with fw devices, they are better than the USB devices available. | 19:35 | |
| OvenWerks | USB was not made for low latency audio by any stretch of the imagination | 19:36 |
| OvenWerks | (this includes USB 1.1, 2.0 and 3.*) | 19:36 |
| OvenWerks | In fact, the USB3.0 kernel drivers and mother board hardware are in many cases worse for profesional audio. | 19:38 |
| OvenWerks | Eickmeyer: which blurb (URL) am I rewriting? | 19:40 |
| Eickmeyer | OvenWerks: A pastebin would be more than adequate. :) | 19:43 |
| OvenWerks | that is what I will send I just wanted to know what is written now. | 19:43 |
| OvenWerks | I certainly want my spelling checked anyway :) | 19:44 |
| Eickmeyer | https://wiki.ubuntu.com/FocalFossa/ReleaseNotes/UbuntuStudio | 19:44 |
| Eickmeyer | It's in the release notes under Ubuntu Studio Controls. Really, if that doesn't spell it out, I don't know what does. | 19:44 |
| studiobot | <teward001> > Due to kernel compatibility reasons, Firewire devices are no longer supported. | 19:45 |
| studiobot | <teward001> OvenWerks: if the kernel still supports FW, then that statement in the release notes is false | 19:45 |
| studiobot | <teward001> Eickmeyer: ^ | 19:45 |
| housecat | might help to rephrase "supported" to "officially supported by the UbuntuStudio project" or something | 19:46 |
| housecat | i expect it's the two different meanings of "supported" that's throwing people off :( | 19:46 |
| OvenWerks | yes that is certainly the problem | 19:47 |
| Eickmeyer | Yeah, sorry, I was in the restroom. | 19:51 |
| Eickmeyer | So, the thing is, it's under the bullet point of "Ubuntu Studio Controls" meaning Ubuntu Studio Controls doesn't support it. So, maybe I should take the kernel compatibility part out. | 19:52 |
| Eickmeyer | housecat, @teward001 ^ | 19:52 |
| Eickmeyer | How does this read: Firewire devices are no longer supported under Ubuntu Studio Controls. Consider upgrading to a modern USB or PCIe audio interface. | 19:53 |
| Eickmeyer | housecat, teward, OvenWerks | 19:53 |
| studiobot | <teward001> that would work, but the release notes are already made, not sure if we should be editing them post release. A blog post clarifying what we mean by support might work | 19:54 |
| studiobot | <teward001> Eickmeyer: but yes I would pull the Kernel part out | 19:54 |
| studiobot | <teward001> since that part is wholly 'false' | 19:54 |
| Eickmeyer | That's what I did. That paste was the entire bullet point. | 19:55 |
| OvenWerks | I suppose that would be fine... but it is not true really. Firewire devices with alsa support will work just fine with -controls, however, if alsa support is not available for a device -controls will not beable to use it. | 19:55 |
| Eickmeyer | Then how does this sound? "Firewire devices are no longer supported under Ubuntu Studio Controls unless they work with ALSA." | 19:56 |
| OvenWerks | s/supported/available/ ?? | 19:57 |
| Eickmeyer | Ok | 19:57 |
| Eickmeyer | "Firewire devices are no longer available under Ubuntu Studio Controls unless they work with ALSA. Consider upgrading to a modern USB or PCIe audio interface to take advantage of everything Ubuntu Studio Controls has to offer." | 19:58 |
| Eickmeyer | ??? | 19:58 |
| OvenWerks | ok | 19:58 |
| studiobot | <teward001> yep | 19:58 |
| OvenWerks | I like putting what does work first rather than doesn't work unless | 19:59 |
| OvenWerks | but, it is harder to make it sound smooth I guess | 19:59 |
| Eickmeyer | If I were to do that, it'd be like, "While ALSA-compatible firewire devices will work, any device not compatible with ALSA will not" which just doesn't flow. | 20:01 |
| Eickmeyer | Also creates a lot of duplication. | 20:01 |
| OvenWerks | yeah thats what I meant | 20:02 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!