He's written some other interesting posts on PulseAudio features too, but this is more well-written and approachable:
Richard G. Lyons, Understanding Digital Signal Processing 
Gareth Loy, Musimathics: The Mathematical Foundations of Music (volume 2) 
r8brain-free-src (high quality sample rate conversion algorithms) 
KVR's DSP forum, frequented by actual pro audio developers 
That's why commercially available phased array microphone systems that actually work are typically one to several meters wide.
I'm actually very surprised that it works as well as it does, based on the sample recordings.
Of course, we'll have the same problems as all the other information in there, that some cheap equipment will have bogus values as someone just copied the ACPI tables from the previous hardware without verifying the information...
If you need an FIR filter, click here and push the button. Generates the code too.
Also if you don't know what you're talking about, kindly refrain from wandering into it in the middle of an article that might otherwise be useful. "An Intro To Beamforming" is a hell of a lot stronger if it doesn't have several flaming errors about basic DSP processing in the middle of it. Those sorts of errors may cause experts discovering you for the first time to avoid your project, not devote time to fixing it.
Had this been a first offense, I would have posted something like: "If you know more than other people, the thing to do is provide correct information. Then we all learn." And I'd have pointed out that going on about "several flaming errors about basic[s]", without specifying what those errors actually are, is just a putdown that adds no real information.
But you've done this many times before, we've given you many warnings already, and you've ignored them. That indicates that you don't want to use this site as intended, so I've banned your account.
Even in this thread people can't quite decide where my remarks lie on the spectrum. (I assure you this is not some game I'm playing to test the waters.) Likewise in a previous thread your banhammer was overruled by the community.
I personally think you're overreacting (calling me a "genuine asshole" ... really, dang?) but I don't wish to cause you any additional stress by being an unintentional canary in this coal mine. I will however deduct a few points for waiting for the thread to die, zeroing out an upvoted comment containing useful information, then banning my account at 1am on a holiday weekend. I know you abhor off-topic meta discussion but, as a fellow moderator who handles forums far larger and friendlier than this one, that's pretty weak. Good luck, you have my word that I won't reappear under a different name.
As for your procedural complaints, holiday weekends (what are those?) had nothing to do with it, 1am enters the picture because it wasn't until 1am that I had time to deal with yesterday's user flags, and there was no 'waiting for the thread to die'. It takes a long time to write comments like the one explaining why we were banning you. Had I wanted to shove this under the rug, I'd not have bothered.
If you'd like to change your ways and treat others respectfully in comments here from now on, I'm more than happy to unban you. Other users have gone from posting assholish comments on a regular basis (I may even have been one myself) to becoming good citizens of this community. If you want to do that too, you're welcome here. But this requires sincerely accepting the model of how HN is supposed to work and doing your best to abide by it. When we give people repeated warnings and they ignore them, it's hard not to conclude that they have no intention of doing so.
Googling a machine learning or signal processing technique from 40 years ago, seeing a link to HN on the first page of Google results that gets it wrong, and having the only comment that actually provides counterpoint or correction missing because you pushed a magic button? I can't believe that's the impact either of us are looking for with regards to contributing to world knowledge.
Likewise I increasingly find myself reading the top comment then scrolling down and squinting at the dimmed out bottom comment. Half the time it's someone being an idiot. The rest of the time it's useful counterpoint or something correct but imperfectly phrased. Groupthink and tone-policing-by-committee may be a bigger problem than someone who dares to use the adjective "flaming" to qualify the nature of errors in a submission.
I too hate dealing with the stack of complaints at the end of a long day, and I too hate seeing the same names causing trouble. It certainly is hard to remain impartial given even a small number of people who are obsessed with the "report misbehavior" button or, worse, those who harbor grudges and abuse the feature. In general those people need to toughen up and the people who are causing the grief need to turn it down half a notch. But HN, in technology and in personnel, lacks the nuance necessary to correct and communicate evolving community standards.
There's nothing more boring (and more damaging) than a public debate around a moderator's standards versus a popular user who bumps against the edge on occasion. Out of respect for your work (and my time) I'm stepping out as that's precisely where this is headed. Good luck with the site, I'm all too aware of the effort you put into it.
> There is a fair amount of academic work describing methods to perform filtering on a sample to provide a fractional delay. One common way is to apply an FIR filter. However, to keep things simple, the method I chose was the Thiran approximation — the literature suggests that it performs the task reasonably well, and has the advantage of not having to spend a whole lot of CPU cycles first transforming to the frequency domain (which an FIR filter requires).
I'm not a real DSP expert by any stretch of the imagination, but applying an FIR filter does not require transforming to the frequency domain. To the contrary: a basic FIR filter just means that the ith output sample is ax[i] + ax[i-1] + ax[i-2] + ... + a[N-1]x[i-N+1] where x is the input, a is the filter coefficients, and N+1 is the (finite) length of the filter. (If the input is all zeros except that x=1, then the input is an impulse and a is the output, i.e. the impulse response. Hence the name: Finite Impulse Response.)
Some very long FIR filters are more efficient to apply by Fourier transforming the input, but that's almost certainly not the case here. It's worth noting that FIR filters vectorize very nicely.
(My FIR description isn't quite 100% accurate. I described only the discrete-time causal case. If you drop the causality requirement (which is fine but can be awkward in real-time processing) then you add negative indices to a. If you switch to continuous time, you end up with a convolution instead of a sum of products.)
I sometimes feel the PC threshold is a bit high in some threads. In this case however even I felt the snark level was painful.
As a productive engineer I often put out internal tools or POCs that would be possible to snark at in this way.
I do however expect that people improve them or explain the better way instead of posting dismissive comments on what this guy has done on top of his open source contributions.
That said: I'm happy to see it reposted although I would prefer if he removed the defence for his previous post as it did add confusion to the new post as well.
2. The module provides infrastructure for other beamformer implementations to be plugged in, my implementation is intended to be a trivial test
3. module-beamformer did not ship (the link points to a branch in my git repository)
What is it about HN that attracts haters of open source POCs? Why don't you contribute and implement an FIR filter? You probably won't, because it's easier to bash someone's work rather than do the work yourself.
My dang-compliant version of the same sentiment would go something like, "If you're going to write posts for public consumption, please consider limiting the topic to things you actually know about. You never know who might read and/or learn from what you write."
Jack is intended as a low-latency audio and midi router for audio production. It routes audio data between applications and whatever analog/digital/midi I/O you have plugged into it that Linux supports reasonably well. In other words it's for build a audio workstation.
So you could, provided you had the skills, quite easily create a audio processing pipeline that will do any type of 'beamforming' you want and more.
Pulseaudio on the other hand is designed as a general purpose desktop and mobile audio daemon that is designed to make it simple to manage typical hardware you find in a typical PC. This sort of stuff is designed to make it nice to have a webcam for simple blog or talking to your mom, not necessarily the best choice if you want to run a music studio from your laptop.