The No.1 Website for Pro Audio
PreSonus Compatibility with Fedora 31 (Linux)
Old 28th April 2020
  #1
Here for the gear
 

PreSonus Compatibility with Fedora 31 (Linux)

I've played guitar casually for years, but recently got it in my head to learn more piano and set up a basic home studio. I've got my guitars, some dynamic mics, and my computer. I'm just picking up an audio interface to stitch it all together, and eventually a good keyboard / MIDI controller.

I'm all Linux all the time these days though, so I've been learning the ins and outs of Ardour. Before I drop a couple hundred bucks on the PreSonus Studio 68c, can a more experienced audio engineer tell from a mile away that I'm about to wind up in a lot of pain by choosing to stay with in Linux for this?

For context, I'm a computer scientist by day, so debugging things on Linux is my bread and butter, and I'm not frightened off by otherwise daunting Linux challenges. That said, music is a hobby, so I'd rather not sink all my free time into more debugging and frustration when I really want to be making music.

Specifics aside at first, does smart money say I could have a shot at plugging in this ostensibly class compliant interface and getting things to just work with minimal jiggling? Or would experience and conventional wisdom say to abandon this angle?

(A small caveat is that I have the guitars and mics to test the trs/xlr inputs and make sure they work off the bat. Still being in the market for a keyboard, I won't immediately know whether the MIDI ports are configured correctly. If the former works off the bat, should I get the latter for free?)

For context: running Ardour 5.12 on Fedora 31.
Old 28th April 2020
  #2
Lives for gear
 

Hi,

I don't have the mentioned Presonus interface nor I currently use Linux for any audio work (except of some single board computers, but there it acts like headless, single purpose audio player/server or audio processor rather than for DAW duties). So following is rather generic talk about issues, you might encounter.

If the interface is USB class-compliant (UAC), there is some chance, it will work. However as there's no (or super rare) vendor support, it's all based on some voluntary work, which is necessary, when particular interface doesn't work out of box.

So there might be a new UAC hardware, which really works out of box with current USB audio driver and no changes or patches are necessary. Usually that means, the interface is rather simple (no effects, no low latency DSP mixer) and fully conform to UAC standard without any necessary quirks.

Next "level" is, the hardware might need some quirk for enumeration, basic audio streaming, rate changes etc. So such interface needs certain workarounds for basic operation. Usually that means implied feedback type (as it's not possible to detect it standard way), overrides of incorrect USB descriptors to properly establish communication with endpoints or create UAC mixer, sending special one time initialisation packets or something similar to change working sample rate. Or for example adding specific delays to give hardware more time to provide particular operation, initialisation or simply ignore some bogus errors from hardware.
If you believe the interface shares some quirks with another one (like common vendor and lineup), but differs only in VID:PID (unique device identifiers), there are param of snd-usb-audio.ko module, which allow you to apply so called quirk_alias. That might come handy, because you don't need to recompile the module, just specify it some initial parameters.

Finally there can be some interfaces with more elaborate hardware DSP mixing, which is basically every interface with more than two I/Os and without visible front panel pot for input/playback blending (such control naturally doesn't need any software support).
In such cases, support for that might be simply omitted, so the interface works for simple playback and capture, but you have no option for direct input monitoring.
Or someone sniffed and reverse engineered those messages at other platforms, added support for that to linux USB audio driver and in result those mixer controls are normally accessible through ALSA device (you can see it for instance in alsamixer). If those messages goes through normal endpoints like standard UAC controls, that's usually easier to add. However it's not unusual, the USB device is composite and besides common UAC and DFU (for firmware upgrade) endpoints there is also HID endpoint (like keyboard or mouse). Vendor use special HID messages to control its DSP mixer. That's however well above usual USB audio quirk and patch for that commonly involves adding few new files to source tree of snd-usb-audio module just for that specific type of mixer.

That's in nutshell, what are typical things related to support of UAC interfaces on Linux.

To be continued...

Michal
Old 28th April 2020
  #3
Lives for gear
 

So what are options..?

Ditch the input mixer option.

Look for some interface with support for its DSP mixer. By briefly looking to source tree, I can see for example Focusrite 2nd gen 18i8 there.

Specifically pick some interface with analog low latency mixer (eg. blend pot). Those usually has just two inputs, except of maybe Behringer UMC interfaces, where is analog mixer even for 8 inputs in case of UMC1820.

Look for some class compliant interface, which has some other control of its more elaborate mixer. For instance MOTU AVB interfaces are class compliant, but has also Ethernet port and you can access mixer and routing control via any web browser.
Recently I spotted also some initial patch for RME Babyface Pro in class compliant mode, this interface has basic control of its DSP mixer via top panel knobs and buttons (no DSP effect control though).

As I've mentioned, I don't use Linux in that fashion anymore. So it's likely better to further ask for specific interfaces at https://linuxmusicians.com/ for instance.

Check commit history at source tree for the module (usually there is interface vendor name in the commit description) also you can see, what the patch is changing.
https://git.kernel.org/pub/scm/linux...usb?h=v5.7-rc3
Also you can find out kernel version, where this commit has landed. Not sure about Fedora 31, but most of distributions doesn't backport any changes (maybe except of some music centric ones, but I have never tried those), but you can possibly try to backport it by yourself and compile new module to /extra directory, which will override the one from distribution kernel package.

Browse through mailing list archives like alsa-devel (there's also bunch of unrelated stuff related SoC development, but you can filter out ASOC keyword from subj)

Finally you've asked also for MIDI.. well, that's usually lot less problematic for UAC MIDI endpoints. You've mentioned you have no keyboard yet, but you can certainly try it with simple physical loopback DIN cable. Just play something to output and capture it back, you can use standard tools in alsa-utils package (aplaymidi, arecordmidi) besides your DAW/sequencer.
But naturally it might be also completely independent from interface, so for instance if you get some piano or keyboard controller nowadays, it's very common, it has also own UAC USB midi port besides conventional 5-pin DIN.

Anyway it's certainly some bravery in that As I've mentioned, I don't use it, personally. Mainly because there are no tools, I like, vendor support, I don't dig some emulation layers and can really steer focus from audio work, but YMMV and good luck with that route!

Michal
Old 28th April 2020
  #4
Lives for gear
 

Just one note, I found some rather recent commit for support of Presonus 1810c (which is from the same "family" of recent Presonus USB-C class compliant interfaces).
It's from February, so I don't expect to be in F31 kernel (maybe in Rawhide though).
https://git.kernel.org/pub/scm/linux...de629c83317f54
So with 1010c this will likely work. Not sure about 86c, might be very similar (and rather small modification of this can be used for support of it), but who knows..


Michal
Old 29th April 2020
  #5
Here for the gear
 

First off, thank you so much for the very thorough response Michal. I've read it over several times and explored lots of your links, and this has been a hugely helpful jumping off point.

Before I go further, while I mentioned the technical side of these drivers isn't my primary focus here, I'm finding it super fascinating. Is there any chance good references come to mind for getting started in kernel / driver development for sound devices? I'd love to read more.


One of my big takeaways: am I right in thinking a major challenge here will be features selectively working? I.e. a binary "it's recognized and works or it isn't" model is not as accurate as the more frightening case that some features work but others don't or are limited. You mentioned the hardware pot mixer working more reliably than DSP for playback. It sounds like a similar case might be inability to alter configs like sampling rate even though I can record from the inputs. Is that a fair characterization?

It's funny you mentioned the Scarlett 18i8; someone else actually just recommended that for Linux specifically, so it might be my new favorite over the Studio 68c. With that in mind, I see the Focusrite Scarlett 18i8 drivers you pointed to on the source tree. That seems promising, but in your experience might the 2nd gen Scarlett drivers there work out of the box with new 3rd gen Scarlett interfaces? (The additional presence of separate 1st gen drivers gives me a sinking feeling.) If they did - terrific. If not, does the task of trying to update those 2nd gen drivers for a 3rd gen device sound daunting enough for a beginner driver developer to justify just buying and making due with 2nd gen?

Driver development comes to my other question: what are the important differences between driver support straight in the kernel vs through alsa? I can see how installing something through alsa could be both
  1. faster than merging into the kernel and waiting for your distro of choice to adopt the next release and easier than
  2. easier than merging and rebuilding your own kernel
Are there other advantages or disadvantages to alsa?

(And your MIDI point makes great sense: I should have thought of the DIN loopback idea, that's perfect)
Old 29th April 2020
  #6
Lives for gear
 

Hi and you're welcome.

Quote:
Originally Posted by fedora96 View Post
...
Before I go further, while I mentioned the technical side of these drivers isn't my primary focus here, I'm finding it super fascinating. Is there any chance good references come to mind for getting started in kernel / driver development for sound devices? I'd love to read more.
Best info is likely there:
https://www.kernel.org/doc/html/v5.6/sound/index.html
especially "Writing an ALSA Driver"

I didn't want to scare you before start . It's just bit more complicated than - it's UAC device, it will work.

Quote:
One of my big takeaways: am I right in thinking a major challenge here will be features selectively working? I.e. a binary "it's recognized and works or it isn't" model is not as accurate as the more frightening case that some features work but others don't or are limited. You mentioned the hardware pot mixer working more reliably than DSP for playback. It sounds like a similar case might be inability to alter configs like sampling rate even though I can record from the inputs. Is that a fair characterization?
Exactly, I wrote that before to tell you about basic issues, which has to be solved, when someone adds support for some USB audio device to Linux kernel. And of course, it isn't binary, there can varying degree of supported features (from basic playback to full DSP mixer control) among different interfaces.
And of course, even some interfaces might still have issues, some had that in past but someone fixed that. At the end, it's mostly reverse engineering and voluntary work.
Analog blend pot is just an indicator, because it doesn't need anything in driver and hence it always work. It's the simplest from of hardware input monitoring. There is just signal from analog input (goes in parallel to ADC), signal from DAC, blend between those and audio output. OTOH, it's has its limits (like if you'd like panning and different level for each input, as it's not an complete analog mixer). That's exactly the reason, why vendors implements DSP mixers, but in that case, you need some software interface to control them.
Or in rather rare cases, it can be also controlled physically using some hardware digital encoders and display, that also doesn't need any software support, as you can do it physically from the front panel.

Quote:
It's funny you mentioned the Scarlett 18i8; someone else actually just recommended that for Linux specifically, so it might be my new favorite over the Studio 68c. With that in mind, I see the Focusrite Scarlett 18i8 drivers you pointed to on the source tree. That seems promising, but in your experience might the 2nd gen Scarlett drivers there work out of the box with new 3rd gen Scarlett interfaces? (The additional presence of separate 1st gen drivers gives me a sinking feeling.) If they did - terrific. If not, does the task of trying to update those 2nd gen drivers for a 3rd gen device sound daunting enough for a beginner driver developer to justify just buying and making due with 2nd gen?
2nd gen seems to be directly supported, tested (at least by authors of commits ). That's safe bet, with particular kernel versions, where its official patch was already applied. If you don't want to further experiment, go with that, it should be still available.
3rd gen might use same protocol to control mixer, but I won't bet on that. Some people reports success with say 3rd gen Solo out of box, but that's its simplest interface from the lineup without any mixer.
Check the questions and followup replies..
https://www.spinics.net/lists/alsa-devel/msg98205.html


You can see where particular VID:PID is added for support of 2nd gen mixer
https://git.kernel.org/pub/scm/linux...784f3298309b3e

If you'd like to add support for another PID of 3rd gen interface (VID will be the same that's Focusrite), then look for occurrences of USB_ID in main quirks table and also in /sound/usb/mixer_scarlett_gen2.c
for example USB_ID(0x1235, 0x8204)
Of course, that will work only in case, the protocol for mixer control will be exactly the same. I'm not sure about that.

Quote:
Driver development comes to my other question: what are the important differences between driver support straight in the kernel vs through alsa? I can see how installing something through alsa could be both
  1. faster than merging into the kernel and waiting for your distro of choice to adopt the next release and easier than
  2. easier than merging and rebuilding your own kernel
Are there other advantages or disadvantages to alsa?
That's not ALSA vs. kernel...
ALSA has two related parts - userspace libraries with associated utils and kernel modules (eg. drivers). Kernel part is included in official Linux kernel source. Libraries and utils live at alsa-project.org.
So if you'd like to add some audio hardware support for a device, the code has to go to kernel. If you want to experiment with new audio hardware, you have to mess with kernel source.
However you don't need to recompile whole kernel. Linux has ways, how to compile just custom module(s), you're working with and load it to running kernel and also override original version the same module, which is part of official package from distribution.
Anywa that's the way, which is suitable just for development or maybe some non-updated personal computer. Naturally if you make own version of some module, and official kernel package in your distro will be updated, you'd need to recompile it again.

Also speaking of ALSA, you can imagine it like lowest level of audio hardware access in Linux. It's also most efficient way. But that has quite few problems, like with sharing of ALSA audio device between different running programs, mixing streams, passing audio from one application to another etc. (it's also possible with sole ALSA library, but it has its drawbacks). That's why most of programs use some intermediate layer, which can help with that and adds some additional feature. Like JACK, Pulse Audio etc.

Anyway, I'm sorry, that I have just some generic thoughts. As I've mentioned, I don't use Linux for audio and don't test any new interfaces there, can't give you some more specific tips.
At one computer I have an internal RME PCIe card, which works also in Linux, but that's it for nowadays. I have super conservative CentOS there, because that's what I like to use for some other work, mainly for cases, when virtual machine isn't enough.
But I'm pretty sure, that someone over linuxmusicians forum will be much more knowledgeable about stuff and current interfaces and give you some better advice.

Michal
Old 10th August 2020
  #7
Here for the gear
 

A few quick follow up notes on the off chance it's helpful if anyone comes across this:
  1. I ultimately decided to go with the Focusrite Scarlett 18i8 Gen3. No guarantees this translates more generally, but I had a lot of success out of the box with kernels 5.6 and 5.7 - no extra drivers needed. That's not to say everything works without a driver, but once it's out of MSD mode (check out the thread in (2) below), lots of the basic functionality works great.

  2. For more advanced functionality like custom routing, check out this thread over at LinuxMusicians where a gen3 driver is under various stages of development for the different Scarlett gen3 models.

  3. Thank you again very much Michal for all the help getting going with this. I'm still going down the rabbit hole, but I've already learned a ton and your advice and pointers starting off were very useful.
📝 Reply

Similar Threads

Thread / Thread Starter Replies / Views Last Post
replies: 4468 views: 1164035
Avatar for Braindedzluney
Braindedzluney 11 hours ago
replies: 83 views: 60812
Avatar for mildewman
mildewman 17th March 2017
replies: 0 views: 206
Avatar for arkada
arkada 6th August 2020
replies: 113 views: 2508
Avatar for Scragend
Scragend 6 days ago
Topic:
Post Reply

Welcome to the Gearslutz Pro Audio Community!

Registration benefits include:
  • The ability to reply to and create new discussions
  • Access to members-only giveaways & competitions
  • Interact with VIP industry experts in our guest Q&As
  • Access to members-only sub forum discussions
  • Access to members-only Chat Room
  • Get INSTANT ACCESS to the world's best private pro audio Classifieds for only USD $20/year
  • Promote your eBay auctions and Reverb.com listings for free
  • Remove this message!
You need an account to post a reply. Create a username and password below and an account will be created and your post entered.


 
 
Slide to join now Processing…
🖨️ Show Printable Version
✉️ Email this Page
🔍 Search thread
🎙️ View mentioned gear
Forum Jump
Forum Jump