i guess midi 2.0 is like ipv6 of audio.

there was big announcement in 2020 with synth companies like yamaha, and also IT companies such as Google, but nothing has came out so far :-)

never seen a product claiming midi 2.0 support

of course got sick for the holidays :-) don't expect much activity pre-NY at LKML.

It is quite obvious that devices that embed Linux, Pipewire and for the app tailored tiled wm, Plasma and similar tools are the future of devices of this category:

https://www.youtube.com/watch?v=fZitBeVx3ow

Self-programmable MIDI controllers are a category where "the product" does not yet exist for doing anything very efficiently at least. E.g., for an artist OSC/Pilot requires whole team of specialists on tour, so it is not really for everyone, and TBH even that demo is "not that amazing" ;-)

Off-the-shelf self-contained Linux based MIDI device where you could setup similar control widgets on touch screen would essentially replace the team of IT specialists with a backpack (on tour).

Such device could be easily larger than e.g., 1010music's Blackbox [1], and it still would be super convenient and cheap the build :-)

[1] Blackbox is quite a amazing sampler and is about the size of two CD covers piled together.

Lol, it seems that doing proactive work to not use systemd is still a thing.

However, I wish some day Busybox could figure out service units given upstream projects prefer them ;-)

Note: I don't really know much of the problem space in this area tbh, and current situation is totally sustainable.

#systemd #busybox

Having used Bitwig Studio a bit now in Linux I can only say that if the lack of plugins is not a problem, Linux is superior audio platform even to macOS and CoreAudio.

Just to name one example of MANY, routing is the most user friendly experience that exist if you need that. In macOS some stuff for MIDI is configured through a some settings dialog I cannot recall anymore where it is located, and for more generic audio routing one has to buy a Loopback from Ameoba Audio. With Pipewire, you just open Helvum or similar tool, and wire the shit.

Comparing anything audio to Windows is not wort of the effort because audio in Windows is a disaster broken from all possible angles :-) I don't know Microsoft's priorities but personally I would fix audio before poisoning world with the worst AI assistant ever.

Through audio I've got into using Niri as my window manager because that topology fits really for "studio alike environment" because it gives a tactical rack/modular like environment, and is a advantage too in that sense.

If ever have to use Windows machine, 'gopass' seems to working replacement for pass (and gpg4win enables yubikey).

cool i did not know this but noticed by accident that gpu-screen-recorder seems to capture also audio from DAW flawlessly :-)

apparently wine 10 uses ntsync out-of-the-box:

❯ lsof /dev/ntsync
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
start.exe 6512 jarkko 12r CHR 10,261 0t0 1155 /dev/ntsync
wineserve 6514 jarkko 9r CHR 10,261 0t0 1155 /dev/ntsync
services. 6518 jarkko 10r CHR 10,261 0t0 1155 /dev/ntsync
explorer. 6524 jarkko 10r CHR 10,261 0t0 1155 /dev/ntsync
winedevic 6533 jarkko 10r CHR 10,261 0t0 1155 /dev/ntsync
svchost.e 6605 jarkko 10r CHR 10,261 0t0 1155 /dev/ntsync
plugplay. 6611 jarkko 10r CHR 10,261 0t0 1155 /dev/ntsync
winedevic 6623 jarkko 10r CHR 10,261 0t0 1155 /dev/ntsync
conhost.e 6641 jarkko 11r CHR 10,261 0t0 1155 /dev/ntsync
winecfg.e 6643 jarkko 10r CHR 10,261 0t0 1155 /dev/ntsync

This happends after creating /etc/modules-load.d/ntsync.conf and "sudo systemctl restart systemd-modules-load.service":

❯ systemctl status systemd-modules-load.service
● systemd-modules-load.service - Load Kernel Modules
Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static)
Active: active (exited) since Fri 2025-12-19 03:31:20 EET; 4min 26s ago
Invocation: 367aac34988a4ed491f826a5670acf94
Docs: man:systemd-modules-load.service(8)
man:modules-load.d(5)
Process: 5939 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=0/SUCCESS)
Main PID: 5939 (code=exited, status=0/SUCCESS)
Mem peak: 2.7M
CPU: 6ms

Dec 19 03:31:20 sysdarch systemd[1]: systemd-modules-load.service: Deactivated successfully.
Dec 19 03:31:20 sysdarch systemd[1]: Stopped Load Kernel Modules.
Dec 19 03:31:20 sysdarch systemd[1]: systemd-modules-load.service: Consumed 445ms CPU time, 89.5M memory peak.
Dec 19 03:31:20 sysdarch systemd[1]: Stopping Load Kernel Modules...
Dec 19 03:31:20 sysdarch systemd[1]: Starting Load Kernel Modules...
Dec 19 03:31:20 sysdarch systemd-modules-load[5939]: Inserted module 'ntsync'
Dec 19 03:31:20 sysdarch systemd[1]: Finished Load Kernel Modules.

https://github.com/vim/vim/pull/18869

#vim

Audio is still a niche in Linux but one can already see the uprising commercial potential due recent years development of e.g., Pipewire, improvements in kernel and projects like yabridge, which is like "Proton for audio plugins".

It's also pretty nice to open audio projects in properly tuned Linux distribution thanks to overall feel of stability and steady response, and off-shelf routing network (thanks to pipewrite), even more so than e.g. in macOS. It's only the smaller plugin ecosystem that really counts.

And this all is fairly recent, happened only during last few years. E.g. in 2019 audio situation was still quite horrible :-) When you make a song, you don't want start your creative process by adjusting audio buffer sizes for fucking Jack init.

a bit over 18 years working from home :-) could not imagine myself working in an office

sysdarch is also arch install optimized for latency instead of throughput (from those grounds inhreits the choice of using ext4 instead of btrfs). making sure that full pre-emption is always turned on, threaded irqs are enabled (for the benefit of USB audio interfaces), default user is added to 'realtime' group etc.

It differs from audio/studio distributions in the sense that I use balanced decisions and choices but don't break the whole system for questionable benefits :-)

It runs Bitwig Studio with yabridge or FL Studio with wineasio really well and that's like the stimuli in the first place ;-)

I think I slowly make it more generic and polished over time because it has sort of its own nice as per use case...

My Arch install scripts soon will almost configure Niri and Noctalia (there's only a single bug in the install script that i need to fix).

I maintain the script proactively so that they retain close proximity to my live install because this can be toolized in kernel debugging situations (e.g., reproduce the same environment to a VM).

Maybe I even distro-name this some day. The first name that came to mind was "Idiocracy'. I have no idea where from that spun off ;-)

https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/sysdarch.git

I've recently started to use Niri in my main desktop PC. First tiling wm where that some how intuitively works for me, and does not require too much configuration :-)

https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/sysdarch.git/commit/?h=main&id=7484242542d5bdd97a507c47959d2117faf6a170

a "one line change moment" ;-)

https://lore.kernel.org/linux-integrity/20251215231438.565522-1-jarkko@kernel.org/T/#u

Somehow these types of patches give more kicks than more complex ones.

Some news outlets etc. seem to translate making translate making support non-experimental into "Rust support getting official". I guess Rust has been "official" past 5-6 years but marked as experimental. I don't understand this type of reporting, or what it meant by "official" to begin with.

Glad previous stuff was merged but new stuff for further streamlining hmac sessions and code around has piled up:

https://lore.kernel.org/linux-integrity/20251214153808.73831-1-jarkko@kernel.org/

Improving hwrng, the prime source of latency issues, has some groundwork laid out, and latency hit should be now stable (as per small variance in expected latency).

After those have been merged it is easy to further to improve hwrng (probably by making it to pool random bytes with fixed size chunk pulls of new data, and serve caller from the pool).

casted my vote in linux foundation tab elections :-)

Iterating HMAC encryption steadily to be great again: https://lore.kernel.org/linux-integrity/20251210172027.109938-1-jarkko@kernel.org/

I don't think it has unsolvable issues but it will need some rework. Just needs a few iterations like this.

I think also that once it is functionally and quality wise significantly improved it makes sense to replace CONFIG_TCG_TPM_HMAC with kernel command-line parameters and set of parameters.

Other remarks that I put mostly here for myself as a remainder (I love Mastodon bookmarks):

1. One thing that was properly handled in the first iteration was also that despite ECC-NIST-P256/SHA256 might be de-facto and pratically everywhere in western countries, there's also large population in a distant country at Asia relyingon SM2/SM3. I.e. we eventually need SM2/SM3 to be univeral.
2. Initialization itself should be *conditional* i.e., it will complain if feature cannot be enabled but that's all. It can be then supplemented with "panic_on_warn" style parametr, if somone has a problem with this.
3. Relying only on null key generated at boot is a great for some systems (laptops/desktops) but for embedded systems especially it is a major performance hit. Thus also persistent root key should be an option.
4. During power on hwrng was the worst glitch. The patch set above already improves the situation by making read request "opportunistic" instead of committing to an amount. No grand plan for this but I do have a sack of ideas in my pocket. This will gradually improve over time with no grand plan tbh ;-)

#linux #kernel #tpm

Second Windows post of the day ;-)

What is the pass alternative for Windows that is fully compatible with pass' database?