You are not logged in.
Pages: 1
I seem to have found a solution, and as usual it's Rui Nuno Capela to the rescue:
sudo apt-get install rtirq-init
The package identifies all kernel threads associated with sound hardware (upon install and every boot), and boosts their priority. I was just able to play a large score without skipping, and I even ran a backgammon match analysis (very cpu-intensive) trying to force it to skip.
Sound processing is all about keeping that buffer filling and emptying on a precise schedule, not CPU power.
I have a question with unclear "appropriate venue", and am wondering what might be the right place, if not here.
On my desktop (16 core ryzen7) a midi file will simply not play smoothly in rosegarden. Most notable are dropouts in the middle of notes.
The same midi file plays just fine on rosegarden running on an ibook (single core g4), a laptop that is over twenty years old. Rosegarden might take a minute to load up, but after that it plays OK without dropouts or stutter.
Things I have tried, in no particular order:
(1) quitting all other applications (yes, including pulseaudio)
(2) disabling unused audio devices - echo 1 > "/sys/devices/pci0000:00/0000:00:08.1/${apropos}/remove"
(3) fuzzing with buffers via qjackctl. this can make the problem worse, but can't fix it.
(4) rebooting with and without #2 above.
So. It's not processing power. It's not conflict with other applications. It's not the fact that there are nowadays four to thirty audio devices on a motherboard to interface with. it's not PA or PW.
What might I be overlooking?
Desktop is running devuan daedelus, with daedalus-updates, daedalus-security, and daedalus-backports. Laptop is running debian unstable, because not much else will install these days. The midi file is a rendition of Bach's Toccata & Fugue in Dm.
That is certainly a helpful resource that I may use once I get past the main.
That said, *it is not working as advertised* for localmodconfig.
Well this is disheartening. After running make localmodconfig, which prompted me for about 200 answers via readline (I just hit enter for all) I went and checked, for example, Networking Support. What I saw:
Amateur radio: enabled Yes. I have no such equipment.
Bluetooth: enabled Module. I have no such equipment.
RFSwithc: enabled Yes. I have no wireless.
Device Drivers -> Network Device Support:
- FibreChannel driver support: Enabled yes, I have no such equipment.
- FDDI Driver support: Enabled yes, I have no such equipment.
- HIPPI Driver support: Enabled yes, I have no such equipment.
- Wireless LAN: Everything enabled yes except Texas Instruments.
- ISDN Support: Enabled yes.
Network device support -> Ethernet device support:
- Pretty much every top-level network card driver enabled, despite my machine only having a Realtek 8169.
And so on. While R8169 was enabled as a module, clearly make localmodconfig *is not working as advertised* because at least hundred of things that should clearly be disabled are enabled.
I am tempted to file a bug report, but who with? devuan, debian, or Mr. Torvalds? I can't identify who is responsible for maintaining Kbuild.
I am not enthusiastic about reasearching the majority of the 6000+ kernel options. Surely there is a better way.
Thank you, the localmodconfig target looks promising - except near as I can figure out, you have to have everything that you're ever going to use plugged in and enabled while you run make? A mild hassle, not an impossibility. Shall test.
I'm going through the kernel menuconfig hoping to create a smaller desktop kernel.
Going through and looking at each option, it's striking how often I come across help text that reads like, "If you don't know what this is, it is safe to say no here" - yet it's enabled.
And there's a lot of help text that looks... legacy. Like, KVM. What common off-the-shelf processors nowadays do not support it?
So anyways, the question: is there a straightforward way to turn off the things that don't need enabling except for owning arcane hardware? I get that having gone to the trouble of writing a module might bias an author to suggest it needs to be on by default!
Entirely aside from philisophical issues with sudo,
NEVER EDIT THE SUDOERS FILE DIRECTLY.
instead, read the man page before trying 'EDITOR=/bin/nano visudo` instead. There are ways to set the order of preferred editors. Read the man page because if visudo suspects anything wrong when nano exits, it does not give you choices or reminders, but instead expects you know which keys to press.
Pages: 1