As we can see in several current threads running 3d simulations to support speaker design is growing. Unfortunately the insights they bring are scattered all over the place and missed by most. Should we collect them and present in a coherent form that allows people to confirm the results and add to a growng body of work?
There is a current thread on approaches to on-wall speakers (happy to make a contribution). There is little on the vibration of cabinets (happy to make a contribution). There are threads on the details of ports (happy to make a contribution but not immediately). There is quite a lot of existing work on horns/waveguides. There is a current thread on speaker/baffle shape. There is a little bit on room acoustics. Etc...
A related topic to presenting and discussing the insights from 3d simulations is how a hobbyist can generate 3d simulations of speaker designs using freely available open source tools in a reasonably efficient manner. There seems to be a remarkably low level of activity and I am guessing it is because people are unaware of how to do it. Of course many have no interest in this sort of thing as part of their hobby but I suspect the number of people with an interest is larger than it currently seems.
There is a current thread on approaches to on-wall speakers (happy to make a contribution). There is little on the vibration of cabinets (happy to make a contribution). There are threads on the details of ports (happy to make a contribution but not immediately). There is quite a lot of existing work on horns/waveguides. There is a current thread on speaker/baffle shape. There is a little bit on room acoustics. Etc...
A related topic to presenting and discussing the insights from 3d simulations is how a hobbyist can generate 3d simulations of speaker designs using freely available open source tools in a reasonably efficient manner. There seems to be a remarkably low level of activity and I am guessing it is because people are unaware of how to do it. Of course many have no interest in this sort of thing as part of their hobby but I suspect the number of people with an interest is larger than it currently seems.
Last edited:
I'd be interested in that. Especially the part about how to generate simulations.
OK we are going on holiday for a week now the kids are back at school and I will leisurely dabble at something when the weather is poor (like now). I will only have a tiny 13" laptop running Windows but hopefully can put together a quantitative discussion about the pros and cons of the 3 approaches to on-wall designs mentioned in the recent thread. Need to find and fix the bug/s running acousto on windows which hopefully will be swift but you never know with windows given it's hostility to code development. For example the lack of proper support for complex numbers is typical and causes grief simulating in the frequency domain.
I will leave more detailed chat about the presentation and disussion of the insights in the simulation results (the more interesting part) and the mechanics of running simulations (the less interesting part) until I have put together something to talk around.
I will leave more detailed chat about the presentation and disussion of the insights in the simulation results (the more interesting part) and the mechanics of running simulations (the less interesting part) until I have put together something to talk around.
Outstanding. IMO, this needs to be benevolent dictator approach to survive birthing around here 🙂 Hoping I'm wrong and cheering for you.
OK the windows bug was found. Windows doesn't support a long double type properly either it would seem. So that's linux and Windows but will need help to check Apple works. Anyway despite the weather I've been told we are going for a walk in the drizzle.
Just a brief note on progress. The weather was excellent while away leading to almost no progress on the project. On return fixed some more bugs and did a bit of work so that a short python script can create a solid model of a speaker, mesh it with gmsh, run acousto using the current (poor) program structure and plot the results. Checked on linux and windows but should work on mac with no more than trivial changes to the build script. See plot below of the initial coarse grid on-wall test case.
Then I looked more closely at the code to see what needs to be changed to create a more reasonable program structure. Hmmm... Then I looked at the code to see why it had ever worked. Hmmm... I should have done this earlier. More haste less speed. At the heart of the code are solid reliable "netlib" C and Fortran routines. The origin looks like an old fortran program converted to C but without moving to a conventional C structure and organisation. It then appears to have been worked on by students that are learning how to program in order to address aspects of their acoustics research. This is common in academia though there is usually someone reasonably familiar with programming in the loop.
The effort to fix the program structure and add what we need looks to be more effort than creating a reasonable program structure from scratch around the "netlib" routines. Seems a pity and I'm wondering if the person leading the original work might have come to a similar conclusion. Ought to post the current code somewhere.
Given there is an existing working code for guidance it should only add a few days. I will post a spec in a while for version 1.0 to see if I have missed any requirements.
Then I looked more closely at the code to see what needs to be changed to create a more reasonable program structure. Hmmm... Then I looked at the code to see why it had ever worked. Hmmm... I should have done this earlier. More haste less speed. At the heart of the code are solid reliable "netlib" C and Fortran routines. The origin looks like an old fortran program converted to C but without moving to a conventional C structure and organisation. It then appears to have been worked on by students that are learning how to program in order to address aspects of their acoustics research. This is common in academia though there is usually someone reasonably familiar with programming in the loop.
The effort to fix the program structure and add what we need looks to be more effort than creating a reasonable program structure from scratch around the "netlib" routines. Seems a pity and I'm wondering if the person leading the original work might have come to a similar conclusion. Ought to post the current code somewhere.
Given there is an existing working code for guidance it should only add a few days. I will post a spec in a while for version 1.0 to see if I have missed any requirements.
Attachments
Impressive. I'm interested to know what an ideal field would look like. Since you want to improve speaker design, you would need to know what constitutes an ideal solution.
Are we looking at the contours of the pressure field here?
Are we looking at the contours of the pressure field here?
If you have to start over is there any remote possibility to make it modern and accessible by using Webassembly or any other means to make be available for web interface?
I'm mostly thinking system optimization automation, but it would be great fun to be able to do small apps around it.
I'm mostly thinking system optimization automation, but it would be great fun to be able to do small apps around it.
Last edited:
It's a plot of the real part of the velocity potential. Pressure scaled and shifted in phase.
Errors come from assumptions in governing equations, discretisation errors and imprecisely known conditions (e.g. boundary conditions, material values,...). The assumption of linear acoustics is fine for quantifying the effects of the front wall (but not for sounds from ports). The discretization errors are significant on the initial coarse grid shown but this is being used to sort things out given it takes about 1 second to run on 1 core for 1 frequency. These errors can be reduced and their influence on the solution understood by refining the grid which will be done when the code is sorted hopefully in a few days. The unknown conditions are only an issue when comparing with a particular speaker which is not the main purpose of the exercise although I will compare against the plots of Toole shown here. He did name the Harman bookshelf speaker used but I seem to have forgotten it. Would be grateful for a reminder.
Webassembly is relevant to the front-end rather than the back-end. Back-end numerical solvers running in parallel are almost all written in Fortran, C or C++. The front-end is initially intended to be whatever scripting language the user wants to use with whatever cad, mesh generation and plotting programs they wish to use. The initial scripting language will be python because that is the scripting language that has been adopted by people doing this sort of thing.
Errors come from assumptions in governing equations, discretisation errors and imprecisely known conditions (e.g. boundary conditions, material values,...). The assumption of linear acoustics is fine for quantifying the effects of the front wall (but not for sounds from ports). The discretization errors are significant on the initial coarse grid shown but this is being used to sort things out given it takes about 1 second to run on 1 core for 1 frequency. These errors can be reduced and their influence on the solution understood by refining the grid which will be done when the code is sorted hopefully in a few days. The unknown conditions are only an issue when comparing with a particular speaker which is not the main purpose of the exercise although I will compare against the plots of Toole shown here. He did name the Harman bookshelf speaker used but I seem to have forgotten it. Would be grateful for a reminder.
Webassembly is relevant to the front-end rather than the back-end. Back-end numerical solvers running in parallel are almost all written in Fortran, C or C++. The front-end is initially intended to be whatever scripting language the user wants to use with whatever cad, mesh generation and plotting programs they wish to use. The initial scripting language will be python because that is the scripting language that has been adopted by people doing this sort of thing.
Infinity Primus 160. Or possibly the second generation Primus P162, but I don't think there's a huge difference between the two.
Thanks for the info. The dimensions are slightly different but not enough to matter given the shape will be squared off and approximated.
PS Have you got a reference to the model for the writeup.
PS Have you got a reference to the model for the writeup.
This project is somewhat similar to one of my hobby programs, a 3D modeler and renderer, just with sound instead of light. Simulating light is all linear algebra, trigonometry, integration, and convolution. I suspect that light is easier because light wavelengths are negligible.
Ed
Ed
There is much in common with perhaps the major difference being BEM involves solving a full complex matrix problem (i.e. memory and cpu requirements get very large very quickly with the number of elements) and it has a bunch of numerical issues such as integrating singularities and frequencies where the matrix problem becomes singular. A well sorted BEM code involves a lot of development time and, as far as I am aware, is only available commercially. What I am looking to put together is a basic code that works sufficiently well to support a hobby interest and fits in smoothly with other tools in the chain like CAD, grid generation, FEM, CFD, general data analysis, plotting and CAM.
Happy to help.
It's in the third edition of Toole's book, section 9.3, page 269 paragraph 3 (and is the first generation Primus 160).
Check akabak, randteam.de under conditions explained you can get a license free of charge.
I use it in combination with 3D modeling of outside of enclosure.
Akabak is windows-only, closed source and doesn't fit cleanly into a 3d simulation work flow. It does however have useful features like infinite baffle, domain coupling, driver coupling, and likely more that won't be in the first version of the BEM code. It is an option for those using Windows but I use linux on a desktop for simulations although I have a tiny laptop with windows on which isn't suitable for large simulations. Other BEM codes like bempp, acousto and few others are also options though many are likely to be linux-only. None of them are a good fit so I started to work on acousto to make it fit better. Then changed to starting from scratch guided by my own BEM coding experience and acousto to some extent.
One of the objectives of the project is to be open, inclusive and working as a group. This means cross-platform tools and if we are to develop them to better fit our objectives they need to be open source. How many will join in I don't know but I am happy to give it a go for a while and see what happens.
One of the objectives of the project is to be open, inclusive and working as a group. This means cross-platform tools and if we are to develop them to better fit our objectives they need to be open source. How many will join in I don't know but I am happy to give it a go for a while and see what happens.
I mentioned Webassembly as it seems to be portable to any device and operating system, but I haven't done anything with it so I might have misunderstood. As I've understood you could compile your C++ code to webassembly and run it with any browser with near native application resourses. Works without browser as well https://webassembly.org/docs/non-web/
https://webassembly.org/getting-started/developers-guide/
I really don't know what it takes to make such projects, I build light weight stuff on web so it feels universal to me and though perhaps these hard core engineering related apps could also live there.
https://webassembly.org/getting-started/developers-guide/
I really don't know what it takes to make such projects, I build light weight stuff on web so it feels universal to me and though perhaps these hard core engineering related apps could also live there.
I'd like a programme please where I can input the size, shape of the speaker, the room size and photo of said room. It then spits all information out including a suggestion of drivers, amplifiers, colour, room decor including a 3d view of the finished article (in-room of course). Then I press a button and a number of speaker builders come up with pre-programmed quotes, build time and ETA. All this takes 2 minutes.
Thank you.
Thank you.