Sing, beastie, sing!

[bluebell]

I found something:

http://www.gsp.com/cgi-bin/man.cgi?topic=jack_umidi

A helper damon that makes external MIDI devices available.

[danboid]

Luc has convinced me to give opensuse another go soon. I'm not married to Arch (or Debian or Redhat) and I need to find out for myself how tumbleweed compares to Arch.

OBS offers more than the AUR or the Arch infrastructure and allegedly it has more packages too. I quite fancy using it to create a custom distro that I can share with minimal effort and I love that you can use it to build packages for other distros too. I'm sure tumbleweed has an easy to use installer too (is it still yast?) which vanilla Arch lacks. I find installing and configuring GRUB tedious so its nice to be spared that. I'll be trying the net install of tumbleweed so as to compare like with like.

[danboid]

All change!

After over 20 years of using Linux as my primary OS at home, I have now ditched it in favour of FreeBSD/TrueOS. TrueOS is a version of FreeBSD customised for home/desktop computer users. The main reason is that no Linux distro supports ZFS as well as FreeBSD and TrueOS do and I value ZFS boot environments so much that I'm willing to switch OS to get them.

The crunch came on Monday night when I ended up installing multiple desktops / many packages in a row under Arch. Something went horribly wrong along the way and I couldn't even boot to the minimal rescue prompt when I tried rebooting. This is exactly the sort of scenario where boot environments save you hours of reinstalling or messing around restoring backups as, under a ZFS-based OS, you'd just boot to the last known working boot environment like nothing ever happened and you're back to using your computer in a matter or seconds. There are various disaster recovery/mitigation things I could do under Linux like using REAR, clonezilla etc but none of them are as painless, fast and elegant as ZFS boot environments and BE's don't involve you using external drives or network shares. Boot envs also allow you to install whole new operating systems without messing with your hard drive config. There's no 'unusing' them or forgetting how better your computing is having them once you've experienced their power!

I have been trying FreeBSD on and off for the last two decades. It doesn't support as much hardware as Linux but I'd have to say that if all your computers hardware is supported and it has the software to do what you want then it is the best choice. This was my problem until very recently because although I badly wanted ZFS, FreeBSD and TrueOS didn't support my laptops graphics card and so I couldn't play videos. That has been fixed in recent TrueOS releases and now my laptops Haswell GPU is fully supported so that I can play 4K videos smoothly via HDMI with mpv. I like ZFS a lot but you can't have a usable 'desktop' computer without video playback.

That was one major blocker to me using FreeBSD at home and the other was MTP support. The last time I gave TrueOS a go I failed to transfer files to/from my LG G4 (Android) phone via the command line mtp tools I tried but I didn't try gmtp, a graphical app for transferring files to/from Android devices for UNIX. I gave that a go last night and got it to work so I decided that was enough to convert me as I know all my other fave open source apps work fine under FreeBSD and TrueOS. Well, almost...

The other feature that FreeBSD is famous for is its superior networking stack. Up until the last few days I was taking the FreeBSD advocates word that it was better that Linux at network stuff but now I have first-hand proof. I have a crappy broadband connection in my flat as I rely upon a powerline broadband adapter to pipe the broadband from my landlords house to my flat. Under Linux, the connection would frequently drop or stall for a number of minutes but I've had no such dropouts under TrueOS. My internet has been rock-solid (if still slow) since.

Whilst I will be using TrueOS or FreeBSD as my primary OS at home from now on, it doesn't mean I can get rid of Linux yet. At home I will dual-boot because there is a fair bit of software that is available for Linux but not FreeBSD. In my case the main non-FreeBSD apps I'm interested in are REAPER and the U-he synths but there are certainly other things too. You can run some Linux apps under FreeBSD but its not 100% compatible, kinda like wine is for Windows apps under UNIX. I will continue to run Linux in work because FreeBSD notably trails behind Linux for virtualisation - non of the FreeBSD virt solutions (bhyve and Virtualbox) have working USB passthrough and hence I am unable to use apps such as Skype for Business under a Windows VM, which is the only real reason I have a Windows VM in work.

[CrocoDuck]

Interesting summary.

I tried some BSD some time ago, PC-BSD (which I believe is the old name of TrueOS) and midnight BSD. While the first was way too slow and sluggish (maybe due to KDE?) the other lacked the support for my laptop wifi card. I wanted to try TrueOS for a while, I will perhaps have a go with a virtual machine. Is it Lumina its desktop environment?

Let us know if you make any audio experiments and how it goes.

[danboid]

Hi crocoduck

Whilst I can recommend FreeBSD as a server OS without hesitation, its much harder to recommend FreeBSD or TrueOS as a desktop OS, even to those who would know how to use it. The main reason is hardware compatibility followed by software availability. The number of people who will be fully covered on all three factors (usability/tech know-how, hardware and software) is very slim indeed so I feel lucky that it covers everything I need to do at home except maybe music production. Saying that, I certainly will be trying out Muse and Ardour etc under TrueOS soon and I'll be back to update this thread when I do.

Yes, TrueOS defaults to Lumina but its garbage so I've replaced it with MATE. I don't like a lot of the defaults TrueOS has chosen - Lumina isn't ready yet (but MATE works great), csh is a shit shell (tcsh is much better as fully supported alternative that lives in FreeBSD base), it now ships with qupzilla instead of Firefox etc but TrueOS is the easiest way to try FreeBSD HEAD without building everything yourself and I'm a big fan of not having to build stuff!

[danboid]

I've just given JACK a go under TrueOS but failed to get it to start, even with the dummy driver.

I have written a reply to the linked article that is waiting approval, asking if the author has any tips to get over my 'bus error'. Maybe he has built a custom version instead of using jackit from the repos?

[danboid]

I have now got JACK running under TrueOS. I uninstalled the 0.124.1 package from the TrueOS repo and installed 0.125 from ports. I've not tested anything yet but at least jack starts from the command line (jackd -r -d oss) and via qjackctl now!

It's nice that the JACK rt option 'just works' under the FreeBSD kernel and also the Ardour package is bang up-to-date.

[gimmeapill]

Good stuff Danboid - please continue posting about your trek into uncharted territories, I'm sure this might be useful to more people

[danboid]

Will do Mr pill!

I wanted a guitar tuner so I tried lingot from ports first but I failed to get that working with either JACK and OSS but thankfully gxtuner compiled easily and works great. Its better than lingot too because you can scale the GUI. lingot is pretty much unusable on a 4K+ display for this reason.

I'm not sure I've found the GUI OSS mixer I want. None of the ones I've tried so far let you select the recording source, for that you have to do it from the terminal like:

Code: Select all

mixer =rec mix

or

Code: Select all

mixer =rec monitor

Although thats a pretty minor inconvenience. dsbmixer is OK otherwise.

[danboid]

Actually, I've just noticed that the GUI mixer that comes with TrueOS lets you set the recording source and works with pulseaudio too so that could well be my best bet for a GUI mixer. Its better than the alternatives I've tried from ports.

[danboid]

There are two things that have struck me in my first couple of days of using JACK under FreeBSD. The first I've already mentioned and that is how nice it is to have RT mode work without needing a patched kernel and the second is that I really appreciate that I can use pulseaudio to get audio under Firefox which continues to work after I start JACK. No need to configure an ALSA loopback device or try to get pulseaudios JACK sink to work.

[danboid]

More good news!

My Scarlett 2i4 works great with both pulseaudio and JACK. I can have Pulseaudio for firefox output to my hifi amp whilst JACK is running on my Scarlett, xrun free. Jack started on my Scarlett on the first attempt - it was almost too good to be true!

The only slight downside is that qjackctl doesn't show the different audio device options when you click on the IO device drop-down menus. Instead, you just have to run:

Code: Select all

cat /dev/sndstat

To list your audio devices, in my case I got:

Code: Select all

Installed devices:
pcm0: <Intel Haswell (HDMI/DP 8ch)> (play)
pcm1: <Intel Haswell (HDMI/DP 8ch)> (play)
pcm2: <Intel Haswell (HDMI/DP 8ch)> (play)
pcm3: <VIA VT1802_1 (Analog 2.0+HP/2.0)> (play/rec) default
pcm4: <VIA VT1802_1 (Rear Analog Mic)> (rec)
pcm5: <USB audio> (play/rec)

So to use my Scarlett I just had to enter /dev/dsp5 into both the input and output device boxes under qjackctl's advanced settings tab and it worked straight away, first time!

This is looking very promising now, I'm sure you'd agree!

[meka]

I'm afraid I have few things in my post that are not clear, so let me try to explain.

• "OSS, jack and pulseaudio working together". Linux can do it to, but on FreeBSD pulseaudio and jack can use the OSS (in my case virtual_oss), hence if I restart jack, pulseaudio is not affected.
• Need for virtual_oss is for several reasons. Most notable one are audio interfaces with more than 8 channels. I talked to virtual_oss developer (and core FreeBSD developer) about why is virtual_oss even there, and his response was that mixing, resampling and clipping handling is much more efficient in user space than to kernel space. Plus, if you, like me, need to plug guitar into your audio interface and record dry sound, but route it to some of its outputs (towards guitar processor for monitoring, in my case), virtual_oss is faster than jack, but only for hardware I/O ports (you can't add FX, like with jack). With this kind of setup, I don't even need jack running with RT priority.
• All of this is usable only in -STABLE and -CURRENT branches of FreeBSD until 11.1-RELEASE is out (end of july), as mentioned virtual_oss developer, Hans Peter Selasky, made a patch that makes latencies on USB based audio interfaces 2ms and up (it was 16ms and up before). If you have non-USB audio interface, 11.0 will work just fine for you
• The point of my blog post was to involve more developers and advanced users to give it a try and get involved in the FreeBSD audio movement. Maybe I should have been more explicit about that. The community is small (hell, we don't even have a release that works decently RT wise on all audio interfaces, yet), but we're making progress.
• What I mean when I say "proper realtime support" is https://www.freebsd.org/doc/en_US.ISO88 ... esign.html. Bare in mind that although the document says "not fully preemptive", that's not entirely true. I did a little experiment: compile something on all cores and play the music using mpv (from the network, so if HDD is busy I don't get glitches). It was glitching like hell, but once you do "rtprio 16 -<pid of mpv>", no glitch or anything. What that command does is put mpv in realtime queue.

I want to be perfectly clear: FreeBSD DAW wouldn't even be possible if software wasn't already written for Linux, first! That's the reason why FreeBSD can not be any better or worse for audio production (once 11.1 is out )) once you have your hardware/drivers configured (OK, maybe less jitters because of RT support, but I can't hear it). Also, FreeBSD has smaller number of audio packages, some due to the given package can not even compile on FreeBSD (bound to ALSA, which FreeBSD supports over OSS emulation), others due to lack of interest in the porters community.

As a Linux user since 2000 and FreeBSD user since September last yer, I really didn't make the switch on whim. I tested two operating systems on my machine (same one) with Linux on SSD and FreeBSD on HDD. Once FreeBSD on HDD gave better results RT wise, Linux was out. When I say better results, that's I/O routing, and not breaking the rest of the system (which happened to me with Linux RT patch).

I, myself, work on having better audio support as much as I can. Since I started using FreeBSD for all my devices except phone, I wrote OSS driver support for DrumGizmo (and became regular dev) and I want to write OSS support for jack2 (I have so little time until Autumn, I don't believe that's going to happen this year). Ideally, other BSDs will benefit from it as they use OSS, too, so my wish is to have more alternatives and be able to choose a perfect one (for one's taste). That being said, Linux is still much better DAW than FreeBSD if you're "just a user".

[autostatic]

There are two things that have struck me in my first couple of days of using JACK under FreeBSD. The first I've already mentioned and that is how nice it is to have RT mode work without needing a patched kernel

You don't need a patched kernel for JACK to run in RT mode.

[danboid]

There are two things that have struck me in my first couple of days of using JACK under FreeBSD. The first I've already mentioned and that is how nice it is to have RT mode work without needing a patched kernel

You don't need a patched kernel for JACK to run in RT mode.

Under most Linux distros/kernels (ie with non Low-latency / RT kernels), JACK fails to start if I try enabling RT mode. I always thought this was a kernel dependent feature? If not, what enables RT mode to work?