Jump to content

Motu A16 + PC DSP Project


SME

Recommended Posts

I placed my order for a Motu 16A unit and an Intel i210-T1 based PCI-E Ethernet adapter.  My plan is to use the 16A as a many channels (16 in/16 out) analog interface and to use it with a Linux PC via Ethernet audio video bridging (AVB) to build a full-featured real-time audio signal processor.

 

This is an ambitious project with a lot of unknowns.  Historically, Motu's support for Linux has been pretty much non-existent, and many user's purposely avoid their products for this reason.  However, AVB Ethernet is an open standard, and theoretically, it should be possible for the Linux PC and the A16 to inter-operate.  We shall see.  In any case, the A16 and related Motu products have excellent audio specs and a strong reputation.  Features such as 8 Vrms and practically non-existent low-end roll-off on the balanced analog outs make these units very attractive for subwoofer use as well.  As another plus, AVB Ethernet devices offer immense flexibility and scalability.  Is 16 outputs not enough?  Easy.  Add an AVB-enabled Ethernet switch and another AVB device such as the Motu Ao24  featuring 24 analog outputs.  Considering the price of the components, this kind of setup is a dream come true for the home theater audio enthusiast.

 

Assuming no compatibility issues arise, the hard part will be building the actual software platform.  I have a bit of a start on this having built my own measurement and simulation tools as well as some experience (over a decade old) with writing real-time audio software, but it will still take quite a while to develop this.  Thus far, I have debated whether or not to release these tools publicly and under what terms.  At this point, I'm leaning heavily towards the open source route.  While I'd love to be able to get paid to work full-time on this project, the reality is that the commercial market for what I have in mind is very limited.  I'd much rather build the platform I and other enthusiasts want rather than having to dumb it down and close it up in order protect intellectual property while catering to a sizable market.  As an aside, I actually interviewed with QSC Audio for a job working on the software for a very similar product.  Suffice to say, they deemed my skills insufficient for the position.  That's their loss as far as I'm concerned, and in retrospect, I'm rather glad my own work can proceed unhindered by non-disclosure and non-compete agreements.

 

I'll update this thread as progress is made.  Expect things to be very slowly at first.  I have a bazillion other projects in progress right now, both for my own audio system and other aspects of my life, not to mention a full-time job that I expect to start soon.  I also have very high standards and would rather not release any source code until I feel that enough groundwork has been laid for it to actually be useful to others.  Stay tuned.

Link to comment
Share on other sites

Awesome to see someone with the brains to start this. I was looking at using a 16A also for my Prepro with my PC. I wont have any crazy 18 channel setups so for me the 16channels was perfect. I still have to continue saving for this product so my plans are still in the works. SO I look forward to your progress.

Link to comment
Share on other sites

If one uses USB for the first device, you can connect a second MOTU AVB devices with ethernet without having to use an AVB switch. I can connect my 1248 and Ultralite for 20 outputs.

 

Not being able to use the MOTU mixer with Linux would be a major drawback for me. Why are you set on using Linux? If you do use Linux, why wouldn't you just use JRiver Media Center with its 64-bit DSP, support for convolution, and control with both iOS and Android apps? Is it because you want to develop your own competing software? Seems like a lot of work if it is just for a hobby. Actually, I guess all hobbies are a lot of work.  :)

 

dlbeck's The Savoy theater at AVSForum use the Motu 24ao and HTPC as his pre/pro. He has DirecTV as a source that routes through the HTPC. I'll be there tomorrow to create a rear row "sweet spot" setting, calibrate the projector, and provide a 3D LUT for the HTPC. 

Link to comment
Share on other sites

Hi mojave,

 

The short answer to your questions is that JRiver is designed as a desktop media player whereas my project will be designed as software for an audio signal processing appliance.  I don't really see my work as really competing with JRiver.

 

No doubt, JRiver has some impressive DSP capabilities built-in, but I don't believe it has anywhere near the power and flexibility that I plan to implement in my system.  It's not just about being able to do bass management with convolution on each output channel but being able to construct arbitrary processing chains with a variety of possible filter types.  I'm already able to achieve a flatter in-room bass response over a wide listening area by using separate filters for each of my 4 subwoofers using a MiniDSP 2x4.  Correct me if I'm wrong, but I don't believe JRiver can handle even this simple task.  The possibilities get a lot more interesting if I can apply a matrix of filters for each combination of pre-bass-management and post-bass-management channels.  This allows me to optimize the integration of each mains channel with the sub(s) without compromise and do more advanced room correction along the lines of Dirac Unison.  The technical term for this kind of room correction is MIMO feed-forward control.

 

I am set on using Linux because it is free, open source, more streamlined, much easier to maintain once installed, and more suited for embedded applications.  It's also much nicer to program for at a systems level, and the open source reference implementation for AVB is written for Linux.  I have avoided doing anything with Windows wherever possible for 1.5 decades, and every time I have to deal with it, I'm surprised by how much slower and more cumbersome it is.  Not only is the OS slower, but the programs and utilities are invariably designed to be used by GUI and often lack sufficient command line capabilities to be usable in a scripting environment.  The bottom line is that Linux is way better for any kind of serious DIY work.  The only thing that Windows really does better than Linux is plays video games, and that's because the 3D graphics vendors refuse to release the full specs for their hardware and put much more effort into optimizing their drivers for Windows, which is most used by gamers.

 

IIRC, the MOTU mixer can be accessed via a web interface, which is effectively compatible with all OSes.  I'll confirm this once I have the unit in hand.  What I'm more concerned about is the ability to stream in/out from the analog ins/outs.  Provided the MOTU is compatible with the open AVB standards, I expect it should work great.  Likewise, if the USB capability is fully compatible with the specifications for USB audio class, then it ought to work fine with Linux as well.  I will soon find out.

Link to comment
Share on other sites

I have no clue so sorry if this is very elementary but is it harder to have slopes that are higher than 6th order?

 

I have seen some other products like Lake and they have the capability of having VERY high order slopes. I would not be worried about have high slopes for my subwoofer but fully active mains it could be very useful. Either way look forward to your progress.

Link to comment
Share on other sites

I'm already able to achieve a flatter in-room bass response over a wide listening area by using separate filters for each of my 4 subwoofers using a MiniDSP 2x4.  Correct me if I'm wrong, but I don't believe JRiver can handle even this simple task.  

yes it can do that, it has 2 filter blocks for dealing with mixing/peq/etc which you can move around as you like. It can't construct arbitrarily complex filter chains as there are only so many blocks you can arrange so perhaps there are some use cases that aren't covered.

 

Have you looked at brutefir? AFAICT it is what you are describing.

 

Have you considered video? I haven't come across anything on linux that matches madvr. This is not to say it doesn't exist but it's another thing to consider.

 

Ultimately it seems there's a lot of time to be burnt on relatively commoditised integration issues vs the actual filter design (which is where I would think the real value of such a project would lie).

Link to comment
Share on other sites

yes it can do that, it has 2 filter blocks for dealing with mixing/peq/etc which you can move around as you like. It can't construct arbitrarily complex filter chains as there are only so many blocks you can arrange so perhaps there are some use cases that aren't covered.

 

Have you looked at brutefir? AFAICT it is what you are describing.

 

Have you considered video? I haven't come across anything on linux that matches madvr. This is not to say it doesn't exist but it's another thing to consider.

 

Ultimately it seems there's a lot of time to be burnt on relatively commoditised integration issues vs the actual filter design (which is where I would think the real value of such a project would lie).

 

I have looked at both brutefir and convolver.  These are both useful starting points that could be incorporated directly if I opt for a GPL license.  I may also investigate ways to improve on their performance.  Additionally, I may explore more exotic filter types that are more efficient to implement because a matrix of many-tap FIRs implemented with low-latency may demand more than even a multi-core Haswell CPU is capable of.  Both Dirac and Audyssey rely on filters that are more exotic than standard biqauds and FIRs to meet their performance needs.

 

I'm not interested in video processing at this time, but I could see exploring it further down the road.  Right now I lean toward doing video processing with completely separate software, perhaps even using separate hardware.  Video processing in general can tolerate a lot more latency than audio processing, and it also benefits more readily from GPU hardware.  The only issue I see with this approach is ensuring synchronization of video and audio over long playback times.  If both the video and audio are streamed using Ethernet AVB, then they can use the same clock and synchronization is assured even if the processing occurs on different hardware.

 

It remains to be seen how time consuming this project ends up being, but I don't believe that JRiver is the right fit for my needs.  Realize that I am looking to implement a signal processor as an isolated component, whereas the DSP capabilities in JRiver were added as an afterthought.  I'd rather not tie myself or my users to any particular media playback program or device as this allows for more user freedom and ensures compatibility with whatever the future may bring.  JRiver has hardly commoditized (I'm American) its DSP functionality being that it's closed source and comes with a lot of unnecessary baggage (i.e., the media player).  Also, it appears that JRiver is designed to be configured and operated from a GUI and does not necessarily support either text-based configuration files or on-line (i.e. HTTP/REST based) configuration.  I'm frustrated by my MiniDSPs due to the fact that they require their own GUI to configure them.  Updating the filters is very tedious and time-consuming as the GUI requires Windows, supports only one MiniDSP device connected at a time, and requires a lot of manual pointing and clicking to modify each part of the configuration.  If their hardware architecture were open, I could feed my filters to the units directly from the software that created them, and this would enable me to do a lot more experimentation than I'm otherwise motivated to do.  With JRiver, I'd most likely find it would do about 90% of what I want, and then trying to get the last 10% to work would be like banging my head against a brick wall.  Without source code, I'd be at the mercy of the program author to fix problems and limitations, and ultimately I'd find myself back in the same place I am now.

 

I don't anticipate much difficulty implementing the basic functionality (e.g. mixing, routing, and filtering), especially given my past experience and the fact that source code for a lot of this stuff is available already.  Instead, I expect to go through a lot of iterations in order to ensure that the basic architecture provides the best possible foundation to build upon.  I also believe good self-testing capability is an essential component because there is the potential for serious bugs to cause equipment damage.  That's not to say that the software would be idiot proof nor would I ever guarantee or warrant anything about the program's operation.  ;)

Link to comment
Share on other sites

Yes the clicky clicky side of any windows app is extremely tedious and that's before you even get to the "one user at a time" interface. My HTPC running windows is my first windows box for >10yrs but I'll take something that actually works for high quality video playback with relatively minimal effort at this point :) JRiver does at least have a web service interface btw so it's as bad as you think, it's far from completely configurable though.

 

Does all the AVB stuff actually work on Linux? I had a quick google but nothing obvious presented itself about kernel support. I suppose distributing audio/video would lead to deterministic processing time on the audio side or some ability to communicate between the audio & video processors. Sounds like a minefield tbh, nice if you can solve it though. 

 

Interesting project anyway, will be good to see how you get on. 

Link to comment
Share on other sites

Here is the JRiver DevZone which provides info on their HTTP/REST commands:  http://wiki.jriver.com/index.php/DevZone.

Here is the MOTU information for JSON over HTTP:  http://cdn-data.motu.com/downloads/audio/AVB/avb_osc_api.pdf

 

I use the JRiver DSP for all gaming, internet audio and other sources besides JRiver as a media player.

 

 

It's not just about being able to do bass management with convolution on each output channel but being able to construct arbitrary processing chains with a variety of possible filter types.  I'm already able to achieve a flatter in-room bass response over a wide listening area by using separate filters for each of my 4 subwoofers using a MiniDSP 2x4.  Correct me if I'm wrong, but I don't believe JRiver can handle even this simple task.  The possibilities get a lot more interesting if I can apply a matrix of filters for each combination of pre-bass-management and post-bass-management channels.

This weekend I setup four zones in JRiver with 6 subwoofers with two subwoofers having the same processing and the other 4 each having their own independent processing. Three zones switch automatically (ZoneSwitch) and are dependent on source material (2 channel audio, movies, TV). The fourth zone is for when the owner of the theater is in the rear row and wants all the bass and surrounds correct for his seat. This zone is manually selected. One of the first three zones needs to be selected for automatic zone routing to take place again. 

 

I've done pre-bass management calibration before on sealed subs such as pulling down the impedance peak and Linkwitz-Transform and then added another layer of DSP for in-room measurements.

Link to comment
Share on other sites

Does all the AVB stuff actually work on Linux? I had a quick google but nothing obvious presented itself about kernel support. I suppose distributing audio/video would lead to deterministic processing time on the audio side or some ability to communicate between the audio & video processors. Sounds like a minefield tbh, nice if you can solve it though.
 

There is already open source code for AVB is on Linux.  Linux is a very popular choice of OS for embedded systems including various stand-alone appliances.  In fact, I wouldn't be surprised if the Motu itself runs an embedded flavor of Linux.  I believe the QSC Audio QSys products use AVB, and I know for a fact that they run Linux.

 

The issue of distributing video and audio together deterministically over Ethernet devices is precisely the problem that AVB is designed to solve.  Streaming of audio and video data over Ethernet is already very straightforward.  Where it gets ugly is ensuring that everything is synchronized to the same clock and that latency is kept to a minimum while providing performance guarantees.  HDMI has this kind of functionality also, but HDMI is designed for endpoint-to-endpoint communications and is a closed standard.  The HDFury products work-around some of the limitations of HDMI, but their implementation is necessarily uglier more expensive, and likely adds a lot of unwanted latency.

 

I believe AVB Ethernet is the future for real-time digital audio/video device interconnection, at least in the high-end/pro arena.  It remains to be seen whether it will become relevant for consumers or not.

Link to comment
Share on other sites

Here is the JRiver DevZone which provides info on their HTTP/REST commands:  http://wiki.jriver.com/index.php/DevZone.

Here is the MOTU information for JSON over HTTP:  http://cdn-data.motu.com/downloads/audio/AVB/avb_osc_api.pdf

 

Thanks for the links to these resources.  It's slightly unfortunate that I have no way of knowing what the JRiver REST interface is capable of.  To quote from the documentation: "This is self documented by the server with an HTML (or WSDL) response. The documentation lists the commands available and the syntax for using them."  Hmm.  I guess I need to buy JRiver to find out what it's interface can do.  :P  It does look like it uses WSDL as opposed to JSON.  :(  It's not that big of a deal, but dealing with XML is slower, uglier and more cumbersome compared to JSON.

 

The JSON over HTTP interface on the MOTU appears to be quite powerful and is undoubtedly accessible from Linux as well as practically any other OS.  I can see it being very useful for live performers whose engineers could program a completely different range of effects with a touch of a button at their console, perhaps going as far as to remap the various pedals and other controller inputs to different parameters.  I'll also appreciate being able to completely automate its configuration for my needs.  The only part that's obviously missing at a glance is the AVB streaming capabilities, and I believe AVB streaming actually happens at the Ethernet layer as opposed to HTTP which is 3 layers removed from Ethernet (i.e., HTTP is defined over TCP, which is defined over IP, which is itself defined over Ethernet).

 

This weekend I setup four zones in JRiver with 6 subwoofers with two subwoofers having the same processing and the other 4 each having their own independent processing. Three zones switch automatically (ZoneSwitch) and are dependent on source material (2 channel audio, movies, TV). The fourth zone is for when the owner of the theater is in the rear row and wants all the bass and surrounds correct for his seat. This zone is manually selected. One of the first three zones needs to be selected for automatic zone routing to take place again. 

 

I've done pre-bass management calibration before on sealed subs such as pulling down the impedance peak and Linkwitz-Transform and then added another layer of DSP for in-room measurements.

 

That's an impressive setup.  Clearly JRiver is a lot more flexible than I had originally ascertained, but I remain convinced that my project is worthwhile.  Of course I don't expect that to be clear to anyone else here (especially JRiver fans  :)) until I've made a lot of progress.  And even then, some may prefer tighter integration of DSP with their media player software, not to mention Windows support so you can avoid needing additional hardware.

 

I most certainly am not one of those people.  I have written a fair amount of code for Windows in my past including some GUI apps and 3D graphics stuff, and compared to programming in a Linux environment, it's totally second class.  Windows may be the superior desktop OS for most users, but Linux is far better for just about anything else. Even games would run better on Linux if it weren't for the chicken-and-egg problem in which both hardware and software vendors dedicate their resources to the OS with the larger market share.  I personally haven't bothered with Windows as a Desktop OS for over 15 years now.  While Windows has steadily improved over that period, I still find it to be substantially slower and the maintenance to be more painful.  The only thing I miss about it at all is the games, but I've been too busy being productive with my computer to have time for those anyway.  :)

Link to comment
Share on other sites

As a more general update, I should receive my MOTU unit by the end of the week, but I won't get to playing with it until at least this weekend.  I've started a new job as a DevOps engineer this week, and have been quite busy getting settled.  I also got a textbook on viscoelastic damping to steal some of my attention.  The wife is out of town over Labor Day weekend, so I should definitely have some time to work then.

Link to comment
Share on other sites

 

 

There is already open source code for AVB is on Linux.  Linux is a very popular choice of OS for embedded systems including various stand-alone appliances.  In fact, I wouldn't be surprised if the Motu itself runs an embedded flavor of Linux.  I believe the QSC Audio QSys products use AVB, and I know for a fact that they run Linux.

 

The issue of distributing video and audio together deterministically over Ethernet devices is precisely the problem that AVB is designed to solve.  Streaming of audio and video data over Ethernet is already very straightforward.  Where it gets ugly is ensuring that everything is synchronized to the same clock and that latency is kept to a minimum while providing performance guarantees.  HDMI has this kind of functionality also, but HDMI is designed for endpoint-to-endpoint communications and is a closed standard.  The HDFury products work-around some of the limitations of HDMI, but their implementation is necessarily uglier more expensive, and likely adds a lot of unwanted latency.

 

I believe AVB Ethernet is the future for real-time digital audio/video device interconnection, at least in the high-end/pro arena.  It remains to be seen whether it will become relevant for consumers or not.

 

 

does the sync protocol in AVB accommodate this sort of latency? It seems like you'd up out of the network/data plane here in order to implement the sort of processing you're talking about whereas the AVB protocol seems ptp based and designed for tight latency syncs for distributed "live" audio use. It would be nice if it can accommodate this sort of thing but, at first glance, it sounds more like you'd need a higher level protocol between your audio & video processors. Having said that I guess the actual sync requirement for AV sync is pretty large compared to the sort of sync that PTP is designed for so perhaps it's not that big an issue anyway.

Link to comment
Share on other sites

does the sync protocol in AVB accommodate this sort of latency? It seems like you'd up out of the network/data plane here in order to implement the sort of processing you're talking about whereas the AVB protocol seems ptp based and designed for tight latency syncs for distributed "live" audio use. It would be nice if it can accommodate this sort of thing but, at first glance, it sounds more like you'd need a higher level protocol between your audio & video processors. Having said that I guess the actual sync requirement for AV sync is pretty large compared to the sort of sync that PTP is designed for so perhaps it's not that big an issue anyway.

 

I'm not sure I understand your question, but I assume you are asking whether AVB can handle playback synchronization of audio and video streams handled by different processors with differing latencies.  I believe that you are right that this is not handled by AVB directly.  Even if it did handle this directly, it would not work in a fully-automated fashion with HDMI devices like HDTVs and projectors.

 

FWIW, I've never gotten A/V sync to work right with my HDMI chain.  Maybe it's my TV's fault, but who knows.  I'm just happy I can switch between devices without major glitches, unlike many people out there.  Having to adjust the audio delay for different kinds of media is a bit of a nuisance, but if I was using a video processor, I imagine I would re-scale and output everything to the native resolution of the TV.  At least then I'd only have to alter the "audio delay" setting for different frame rates.

Link to comment
Share on other sites

I got my Motu 16A over the last week and got to play a little bit last weekend.  It is a remarkably compact unit considering its capabilities.  When I first flipped it on, I heard a reassuring click sound after a second or two, indicating to me that there is likely a relay to prevent unwanted power-on/off thumps.

 

Most of my time this past weekend was spent getting the Intel I210 Ethernet card to work in Linux with the igb_avb driver as opposed to the vanilla igb one.  For some reason, I got a kernel oops when trying to load it.  I spent a lot of time trying to troubleshoot that.  Admittedly, I don't have a lot of experience debugging actual kernel code.  Despite the oops, I was still able to do the software configuration for the card, but it wouldn't talk with the Motu and closer inspection suggested that the network packets were being mangled.

 

Then I tried booting with a different kernel version, and I also recompiled with a switch to "disable packet splitting".  The alternate kernel version fixed the oops, and I was able to have a meaningful exchange with the Motu.  I'm not sure if it was the new kernel or disabling of packet splitting that fixed the problem with the mangled packets.  In any case, I configured a DHCP server on my Linux system and the Motu happily configured itself this way.  I was able to access the web interface and update the firmware to the latest version.  Success!

 

With basic networking up and running, I can now experiment with the AVB-specific features.  Next, I will try to compile and run the various daemons for managing stream reservations, multicast MAC address allocation, and Precision Time Protocol, and then I will look at the tools for device enumeration, discovery and control.  Then I can try streaming audio from/to the inputs/outputs.  There is example source code for all of these functions with the state caveat that the functionality is not complete.  My effort will be to understand the code and modify it as needed in order to incorporate into my own application and make it complete.

Link to comment
Share on other sites

a new paper published by Dirac might be of interest here - http://diracdocs.com/ISEAT15_Brannmark_Sternad.pdf

Thanks!  I will need to take the time to read it later in the week.  It looks like they cover a lot of detail on their MIMO correction technology at a "mid-level" audience.  In other words, they don't dumb it down too much by replacing technical jargon with marketing speak, but they also don't get into all the math either.

 

After this weekend, I decided to shelve the AVB part of my plans for now.  I fought with a fair number of bugs while trying to get the basic examples to work.  I expected to encounter as much, but what I didn't expect so much complexity in the "user level" code itself, particularly for streaming as a sender.  The "simple" example relied on 2-3k lines of code plus an external lib that's specific to the NIC chip I'm using.  While I could most likely adapt what is there to work for my purposes, a lot of that effort would be wasteful because the project will evolve and libraries will be made to mostly abstract out that mess.  On the plus side, I did get to play with AVDECC, which is a higher layer protocol that allows for device discovery, enumeration, and control.  This tech looks like a real boon for the pro-world where the flexibility is enormous.  There are GUI apps either already in existence or under development that allow one to see every audio device on their local AVB network and operate whatever controls are exposed by those devices.  Ideally, the standards will facilitate completely plug-and-play interoperability between a wide variety of devices.  From what I've seen so far, it looks like it has a lot of potential to accomplish this.

 

So after fooling around with AVB, I plugged it in via USB, and as best as I can tell, it works fine in Linux as just a sound card with a bazillion channels.  That'll probably do well enough, and I can leverage the excellent jackaudio library to get the core processing code implemented quite quickly (relatively speaking, given my full-time job and other stuff).  Once AVB matures, it's likely that streaming functionality will be exposed through Jack, possibly on non-Linux platforms too.

 

My first goal will be to reproduce the DSP capabilities I have already with the goal of getting off the MiniDSP stuff.  I'll take my time getting there because I want good built-in testing before I trust this stuff driving expensive downstream equipment.  I'll likely incorporate an existing convolver code to start with, but I may end up rolling my own eventually to try to get better performance and/or less latency.  Or I may experiment with more unconventional filtering schemes.  It's a wait and see thing because I'll need to do my own performance study to determine the best course for my "requirements".  Just to note, if I were to implement all of the processing I want for my current living room system using purely FIR filters, I'd need something like 84 FIRs running simultaneously, and they'd need a lot of taps.  My guess at this point is that I'm going to need to look at more efficient filters to do the job here on a single CPU, especially if I want lower latency, but I won't know for certain until I've given it more study.

Link to comment
Share on other sites

  • 10 months later...

This thread deserves an update.  As stated in my previous post, I decided to not worry about AVB for the time being.  It appears to be a very promising technology, but I have no immediate need for it.  I have edited the thread title to reflect this change in focus.

 

After enduring a bit of struggle (first 3 units were defective), the Motu A16 and PC DSP combo is working out beautifully using just the USB interface.  So far, I have yet to observe any glitches or dropouts in this part of the chain.  The base latency (without any delaying filters) is 16 ms.  I could make that lower, but it's not really a problem for me right now.  I can just set all my speakers to be "further away" in my AVR.  I think the AVR can give me 40 ms or so.  Where I might want less base latency is when I start using filters that delay the signal because the latencies are additive.  At the same time, DSP throughput is much better with higher latencies, especially because this is implemented on a PC instead of a more specialized embedded system.  Nevertheless, a PC CPU has a huge amount of processing horse power and a lot more flexibility.

 

I recently decided to dig in a bit on how to implement FIR convolution.  I looked at the Convolver and BruteFIR programs again, and i did a bit of research into the algorithms.  I concluded that neither programs fits my needs especially well at the moment.  Both appear to be quite dated.  BruteFIR at least had some maintenance done in 2013, but it looks like work on the core engine stopped in 2004.  Code that's hand-tuned to run well on machines of that era won't necessarily run well on today's machines.  The compilers of today may produce better assembly code than is in those libraries.  Furthermore, both projects appear to be abandoned at this point, and the source code isn't really pretty enough to make me want to start hacking on it.

 

Last night, I prototyped a uniform block FFT-based convolver in Python in about 70 lines of code.  That gives me confidence to go ahead and write my real-time convolver from scratch.  It'll take a lot more than 70 lines of code to do the job, but it shouldn't be too hard.  I'll still rely on a separate library for the Fast Fourier Transform as there are a few good options for this.  I also understand how to do non-uniform block-based convolution, but this requires a more involved implementation with multiple threads.  It may be worth it to do later if I end up relying on lots of long FIRs as the mainstay of my filters.  However, I may need to do something more clever because I'm trying to matrix process 6 or 8 inputs (5.1/7.1) to 16 different outputs (5 active bi-amped speakers and 6 sub outputs).  I don't even think there's enough bandwidth between CPU and main memory to handle that many filters if they end up having a lot of taps.  Maybe a GPU could do it, but a GPU is even less real-time friendly than PC CPU.  OTOH, it'd be really nice to be able to switch-in a few long FIRs while experimenting, and then I can look for more efficient ways to implement the filters if need be.

Link to comment
Share on other sites

 

I recently decided to dig in a bit on how to implement FIR convolution. I looked at the Convolver and BruteFIR programs again, and i did a bit of research into the algorithms. I concluded that neither programs fits my needs especially well at the moment. Both appear to be quite dated. BruteFIR at least had some maintenance done in 2013, but it looks like work on the core engine stopped in 2004. Code that's hand-tuned to run well on machines of that era won't necessarily run well on today's machines. The compilers of today may produce better assembly code than is in those libraries. Furthermore, both projects appear to be abandoned at this point, and the source code isn't really pretty enough to make me want to start hacking on it.

What are your requirements (that aren't satisfied by brutefir)?
Link to comment
Share on other sites

OK, are you using an AVR or no?

 

I thought you werent but saw you did mention AVR. Nice to see updates and progress still happening.

 

Yep, I'm using an AVR and will be for a while still so that I can decode HDMI/HDCP signals.  I believe alternative arrangements are possible, but I'm not too concerned about that right now.

 

It's why got the Motu A16 with 16 analog ins and outs.  It *just works* with a bit of extra latency in the chain.  I'm not one to fret about the extra ADC/DAC conversion either, but I'll probably eventually arrange for 2 channel playback directly to go directly to the DSP.

 

What are your requirements (that aren't satisfied by brutefir)?

 

 * optimization for modern CPUs (2004 was a long time ago, and what was optimal then may be suboptimal now)

 * minimal trade-off between number of taps, latency, and throughput

 * clean, modular, minimalistic code with clear separation of concerns

 * non-viral software license

 

BruteFIR is written as a standalone program, and its internal architecture is essentially flat.  The source code is about 21k lines.  That's about twice as big as my entire code base, and my code is better organized and better commented (IMO).  BruteFIR would require substantial re-factoring to bring it up to these standards.  Even the code for the core functionality is messy and would require some surgery to cleanly extract, and if I want more performance than uniform block convolution can provide, then this would need to be completely re-written.  The author notes as much in the documentation, implying that non-uniform processing would require a complete re-write.  Lastly, the point about a non-viral (i.e., not GPL) software license is relevant because it forces me to commit to terms I'm not ready to commit to.  I don't know if I'll make this open source, and if I do, I lean towards a more permissive license like LGPL or MIT that's incompatible with appropriated or even linked GPL code.

 

Edit: Err, the bit about BruteFIR having a flat internal architecture may be a bit of an exaggeration as it does support multiple types of digital audio interface, but the core functionality itself is quite flat and the code is quite verbose/disorganized.

Link to comment
Share on other sites

I think I finished my first real-time FIR implementation.  It passes all the automated tests, and I am doing a bit of a burn-in (letting the code run for a while with outputs disconnected) on it now.  I'm only using a uniform-block method for now because it was a lot easier to do.  I'm testing with the same filters I am using on my OpenDRC-AN units.  If everything looks healthy in several hours or so, I'll start the work of porting over my OpenDRC-AN filters to my custom DSP.  CPU usage with 4 x 6144 tap FIRs running with 48 kHz and block size of 256 appears to be in the low single digits or even less.  I'll have to do more serious benchmarking once I'm more confident that it's fully working and make the time to do it.

 

If all looks good after the burn-in, I'll start the process of porting over all the filters I'm using on the 3 X OpenDRC-AN and MiniDSP 2x4.  I'm looking forward to getting the MiniDSP stuff out of my chain, especially because I've been having a lot of power outages here lately, and the DC thumps from the 2x4 are really unnerving.

 

I also implemented gain and mix blocks.  The gain block is pretty trivial, and I could accomplish as much using a biquad, but it makes things feel more complete.  The mix block is the last tool I need to implement bass-management and matrix processing in general.  Once I migrate bass management from my AVR to the DSP, I'll be able to do whatever BEQ I want.  :)

Link to comment
Share on other sites

I'm now running live with the same filters as I used in the OpenDRC-AN but ported to the custom DSP system.  The OpenDRC-AN units are still in the chain but are running bypass-type configurations.  Everything measured nearly identically after the switch, so the new code appears to be working very well.

 

Now, I'm waiting for some audio adaptors I need from Monoprice to hook my subs up directly to the Motu.  Once those arrive, I plan to migrate the filters off of the MiniDSP 2x4 as well.  Then I'll remove the MiniDSP stuff from my signal chain and re-optimize the gain structure.

 

I think the next capability I'll work on is the ability to stream metrics out.  I realized that the Motu UI doesn't provide any precise level measurement.  To do the bass management in my DSP with confidence, I have to make sure that the signals for each channel are level-matched, not just with respect to SPL at the MLP but also with respect to the signal level within the unit itself.  Any inter-channel variation in output level in my AVR could throw things off.  Having precise signal level meters would be helpful for this as well as other things.  That work would hopefully lead to streaming actual audio data both in and out of the real-time processor and ultimately over a computer network.  But using non real-time buffered streaming rather than a real-time AVB network.  I'm thinking like a web-based dashboard for monitoring and control.  I'm thinking hard about how to build a full-featured web-based user interface around this system.  That would be a real big project.  IMO, UI work is not so mentally challenging but always takes forever to do.  Yet, this project could reach a lot more people that way.

 

I'm still totally on the fence about whether it should be open source and whether it should be part of a commercial product.  (These are not exclusive things.)  Admittedly, I don't know much of anything about the various software packages in the pro world whose functionality might overlap with mine.  The trouble with doing anything commercial, of course, is always the commercial part.  You have to make the technology, and then you have to get people to buy it, not necessarily in that order of priority.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...