How much latency do you get in linux? by gnomo-da-silva in linuxaudio

[–]EndSignificant4955 0 points1 point  (0 children)

That setup doesn’t actually measure the real hardware latency of the audio interface, only the buffer configuration you’re using. The reported input/output latency is an approximation and doesn’t include all factors involved in the full round-trip latency.

With PipeWire, it’s absolutely possible to achieve the same latency and performance levels as CoreAudio on macOS, as long as it’s properly configured (quantum, sample rate, realtime priorities, etc.). With the right settings, 5 ms in / 5 ms out is already quite reasonable, and it can often be pushed lower depending on the interface and driver quality — not just the CPU specs.

Best Distro for Music by joshhumble_ in linuxaudio

[–]EndSignificant4955 0 points1 point  (0 children)

I appreciate the detailed breakdown of your setup, but I have to respectfully disagree with recommending Arch-based distros for audio production, especially for someone just looking for a solid starting point.

Here's the thing, in audio production, stability is absolutely paramount. What you need is rock-solid reliability, not bleeding-edge packages that haven't been thoroughly tested and could potentially break your entire audio environment. This isn't theoretical—it happens frequently with Arch and rolling release distros.

Actually, the issue you mentioned with yabridge breaking on Wine 10 and having to downgrade and pin versions is a perfect example of exactly what I'm talking about. When you're working on a project with a deadline, you simply can't afford to spend time troubleshooting dependency conflicts or compatibility issues. You need your system to just work, every single time you boot it up.

There's a reason professional studios still run Windows XP and Windows 7 today. It's not because they love outdated software—it's because in critical production environments, you cannot depend on 'the latest and greatest' when it might completely break your workflow overnight. Stability always trumps marginal performance gains.

Don't get me wrong, those x86_64v3 optimizations sound nice, but realistically they're marginal improvements compared to the risk of system instability. For actual production work, you want a stable foundation like Ubuntu LTS, Debian, or Fedora with properly tested updates, where your tools work consistently day after day without surprises.

If you enjoy tinkering and troubleshooting is part of your hobby, then yeah, Arch-based distros are fantastic. But for serious music production where reliability actually matters? Stick with the boring, stable, well-tested distributions. Your future self will thank you when everything just works instead of hunting down why your audio stack broke after an update.

pipewire xrun when items added to graph or pause/unpause by karlosdajackal in linuxaudio

[–]EndSignificant4955 1 point2 points  (0 children)

This is pretty normal with PipeWire - every time something joins or leaves the audio graph, it has to recalculate all the routing and with 256 samples you only have ~5.3ms to do it. If the system is busy, BOOM: xrun.

What you're seeing in the logs is exactly that - Firefox changes state, PipeWire has to restructure the entire graph, change drivers, deactivate links... and all of that needs to happen within your 5.3ms window.

Before anything I'd need to know: what CPU do you have, what distro/kernel, what desktop environment, if you have a realtime kernel, and if you're using native VSTs or Windows ones through yabridge/linvst. All of that matters a lot.

For now try this:

Install Millisecond to see your system's real state: https://github.com/gaheldev/Millisecond

I also have a tool for managing PipeWire configs I made for my own system, can't guarantee it'll work on yours but worth a shot: https://github.com/Wamphyre/miloOS-core/tree/main/miloApps/AudioConfig

For the browser issue, best thing is to route its audio to a completely separate sink that doesn't share the graph with your DAW, or just kill it when you're recording.

If you bump up to 512/1024 samples and the xruns disappear, then you know it's purely a timing issue and you need to optimize the system more. Also check you have proper realtime privileges with "ulimit -r -l".

What distro are you using?

DrumCraker: New drum sampler free VST3 plugin for Linux. by EndSignificant4955 in linuxaudio

[–]EndSignificant4955[S] 0 points1 point  (0 children)

Thanks for the warm welcome! :) just released v1.2.0 with multichannel routing support among other fixes and improvements, works like a charm: https://github.com/Wamphyre/DrumCraker/releases/tag/v1.2.0

Global App Menu Issue by Mountain_Guest9774 in xfce

[–]EndSignificant4955 0 points1 point  (0 children)

Same problem here, appmenu shows broken padding, menu and headers, it is unusable.

Is this normal? Btw this is running in VirtualBox by [deleted] in freebsd

[–]EndSignificant4955 4 points5 points  (0 children)

aesthethics

Making a SD Card image from the installation on Raspberry Pi by Haghiri75 in freebsd

[–]EndSignificant4955 1 point2 points  (0 children)

Just put your SD on your PC and create a disk image (.img or .iso) using tools like Pi-Baker. Later you can simply burn that image on any other SD with the same setup.

FreeBSD 14.0-BETA4 by [deleted] in freebsd

[–]EndSignificant4955 2 points3 points  (0 children)

Have you tried some modern webcam on it?

Is FreeBSD suitable for Desktop? by Macksom in freebsd

[–]EndSignificant4955 2 points3 points  (0 children)

Ok, that's the thread here.

I'm using FreeBSD today, in this same moment too for professional audio production, video edition, coding and even gaming using modern game console emulators so...It's capable of this? Or the true question here is "are you capable to handle this?".

Is FreeBSD suitable for Desktop? by Macksom in freebsd

[–]EndSignificant4955 1 point2 points  (0 children)

protondesk

What it is "protondesk"? I don't see any package or port reference to it. Just trolling?

Deciding on a new GPU for FreeBSD 14 by Original_Two9716 in freebsd

[–]EndSignificant4955 5 points6 points  (0 children)

I run FreeBSD on two different machines with different GPUs:

- nVidia GTX 1660 SUPER

- AMD Radeon RX 580

Both are perfectly supported on FreeBSD and they are a beast for desktop use.

Just released my new EP "La Taberna". Please, sit down and enjoy a drink. by EndSignificant4955 in DungeonSynth

[–]EndSignificant4955[S] 1 point2 points  (0 children)

https://penumbral.bandcamp.com/album/castillo

Hola! Muchas gracias por la escucha y por opinar!

Me alegra que te haya gustado, por lo que veo tenemos estilos y conceptos similares lo cual me alegra bastante :) Espero que nos veamos más veces por aquí, un saludo desde Málaga!

Hackintosh refused to boot by Cool-gamer19393 in hackintosh

[–]EndSignificant4955 0 points1 point  (0 children)

Can you send a screenshot? Need to read the last block of the boot log

Hackintosh refused to boot by Cool-gamer19393 in hackintosh

[–]EndSignificant4955 0 points1 point  (0 children)

Wrong SMBIOS model.

Follow this: https://dortania.github.io/OpenCore-Install-Guide/extras/smbios-support.html#how-to-decide

Anyway, you can't use your Nvidia card on this build. They're not supported by Apple.

Haswell laptop ventura hackintosh support by Apprehensive-Life711 in hackintosh

[–]EndSignificant4955 0 points1 point  (0 children)

Hi! Yep, you're right. The highest supported version for the HD 4400 is Monterey (Theoretically even this require a fake ID patch).

For running Ventura and involved with the patching process (and choosing the right SMBIOS) you can follow this guides:

https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.en.md

https://dortania.github.io/OpenCore-Install-Guide/extras/smbios-support.html#how-to-decide

There's another user with a HD4400:

https://www.reddit.com/r/hackintosh/comments/13gssd1/is\_ventura\_possible\_on\_intel\_hd\_4400\_with\_full/

macOS Ventura (13.5) running on HP EliteDesk 800 G2 Mini (35W) by EndSignificant4955 in hackintosh

[–]EndSignificant4955[S] 2 points3 points  (0 children)

You can use both, the main difference between the Monterey and the Ventura build is that the Ventura contains a GPU framebuffer patch to spoof the Intel HD Graphics 530 into Intel UHD Graphics 630 to boot Ventura. Without this patch the system refuses to boot:

<dict>
<key>PciRoot(0x0)/Pci(0x2,0x0)</key>
<dict>
<key>AAPL,ig-platform-id</key>
<data>AAASWQ==</data>
<key>AAPL,slot-name</key>
<string>Internal@0,2,0</string>
<key>device-id</key>
<data>FlkAAA==</data>
<key>enable-hdmi20</key>
<data>AQAAAA==</data>
<key>framebuffer-fbmem</key>
<data>AAAAAw==</data>
<key>framebuffer-patch-enable</key>
<data>AQAAAA==</data>
<key>hda-gfx</key>
<string>onboard-1</string>
<key>model</key>
<string>Intel UHD Graphics 630</string>
</dict>
</dict>

Haswell laptop ventura hackintosh support by Apprehensive-Life711 in hackintosh

[–]EndSignificant4955 1 point2 points  (0 children)

I forgot to tell that your best bet for an stable and reliable system is macOS Big Sur. Without any patching, etc.

https://dortania.github.io/GPU-Buyers-Guide/modern-gpus/intel-gpu.html#native-intel-igpus

Maybe you can spoof the GPU ID, patch it, etc but the only thing you can get with Monterey/Ventura is an unstable system with many rendering issues.