Not sure I understand. Soffit mounting (in-wall) is what is used when cost is no object and a whole room is built to maximise high fidelity by removing all early reflections by removing all close objects and guiding the early sound past the listener. Technical types obviously rather than audiophiles with monstrous flashy speakers on display in the middle of their dedicated listening rooms.
Getting high fidelity on-wall is challenging (i.e. fun) but if the speaker is designed to require the presence of the wall it can be done to a high standard. Not quite to soffit standard but close and probably ahead of what is typically done with speakers part way into a room. Of course one cannot generalise too much with the acoustics of shared living spaces in the home which are generally fairly poor with a range of things causing issues.
My experience with the OSMC project is that you need clear and well-defined design targets to get through such a group project. Don't start designing things before the targets seem to be okay with most/many/some of the fellows in the group. Once things start rolling, try to stick with those targets -- except if there is a very good reason to change. That said, I believe the opening posts already is a good start!
What I am missing so far in your approach is that you'll need to build prototypes along the way, take measurements, compare with the models, revise the models and the design accordingly, build new prototypes, and take new measurements. This needs time, a workshop, measurement equipment, and money to buy parts.
Go for it!
What I am missing so far in your approach is that you'll need to build prototypes along the way, take measurements, compare with the models, revise the models and the design accordingly, build new prototypes, and take new measurements. This needs time, a workshop, measurement equipment, and money to buy parts.
Go for it!
The OSMC github is more or less just the "endpoint" of where the final documentation lives. All the design discussions were done in the diyAudio thread. Not the most structured method, but it worked. I guess we were lucky that the people involved in the OSMC design were mostly decent and interested in bringing the design forward in a sort-of structured way.
That is very good to know. This makes ABEC/AKABAK free software for this project which is obviously open and non-commercial. I don't have Windows on my number crunching machine but can test small models on a laptop. It might be better if a regular Windows user with an interest in the group project and performing BEM simulations obtains a student license. Anyone?
If not and I find no suitable open source equivalent (not aware of any at present but have not looked closely) I will contact the author about options. Thanks again.
Reasonably accurate room simulations tend to require reasonably accurate handling of absorption by curtains, furniture, people, passive room treatment, active room treatment, subs, etc... The practical handling of this leans more towards a FEM-type with ray-type acoustic approach rather than BEM. It can be done but isn't the standard approach.
I run almost every simulation on my laptop, there are practical limits to ABEC/AKABAK that mean that high element counts should be avoided, infinite baffle sims save time too and may be a reasonable enough approximation to the on wall placement at least to get going. Restricting the frequency range is another good way to not waste computer resources.
Making the CAD models and setting up the simulations (particularly if the program is unfamiliar) dwarfs the time spent to calculate the answers. Even Rene Christensen states the same in his interview on Erin's Audio Corner.
That was my point too, maybe it wasn't clear. Every room and placement will be somewhat different so how far is it worth going when simpler solutions get most of the right answers.
Andy, if you are running Linux, you can probably use a windows emulator for VituixCad2. There will be a small performance hit, but Vituixcad processes so quickly it would not be noticeable. You can also set up a windows partition. I have never done this, but I have used machines that were set up this way... very slick.
Lost my previous reply when the site was upgraded and thanks for the encouragement.
What I would like to happen with this project is for the group to spend significantly more time quantitatively evaluating the options and 3D details before getting involved with building and measuring prototype speakers. This will initially mean a degree of evaluating software to determine what is useful in practise and what is likely to be too much work.
As mentioned above the first task I have picked up is evaluating software suitable quantifying the problem with on-wall mounting of a conventional speaker compared to away from the wall and in-wall and then to quantify the 3 alternative methods mentioned above to tackle on-wall mounting. The conventional way to do this in industry is with BEM software although there are alternatives. Others have positive experience with commercial software like ABEC/AKABAK and COMSOL but only limited numbers of people have access to commercial software making it a less than ideal speaker design tool for the DIY community. Nonetheless if freely available and usable BEM or equivalent software cannot be found it is likely we will ask for a student version of ABEC/AKABAK to use by someone for this open non-commercial project.
Initial progress on the BEM task has been modest but it is early days. There is a fair amount of software out there but none appears to be in an immediately useful form for us. Some effort required. Two of the projects I knew from the past and had hopes for have dropped their BEM software. I am currently looking at acousto but it took most of a day to install and get the first results out which don't seem quite right but that is likely to be my needing to understand and sort things out a bit more. I will persevere for a day or two and then look at the bempp framework which looks very good in some respects but rather less so in others. If neither pan out I will either fallback to commercial BEM software to progress the design aspects of the project or bring forward looking at software suitable for room acoustics which will also be able to solve the relevant acoustic equations albeit in a less efficient manner.
The openly available CAD software side looks a lot healthier than the BEM side. Lots of projects are using the opencascade solid model engine which supports STEP files and hence exchange with commercial CAD packages. Setting up a parametric solid model can be done in several of them. It likely takes a few hours of user time to setup the parametric geometry but subsequent modifications can often be made in seconds by changing the value of the relevant parameter/s. Every BEM/FEM/FVM/... 3D simulation unfortunately takes a lot of clock time to run but the user can do other things while they do.
I have a slow laptop which could be used for the job but it is currently awaiting a new hard disk. I have emulated linux on a windows laptop before but not the other way round. Wouldn't you have to pay £100+ for a copy of Windows? Does MS still sell Windows to people rather than businesses? It is probably not a task I would pick up unless I needed the software.
OpenSCAD is functional as is FreeCAD, both can do what is needed and may be preferred by Linux users as they will run natively. The user interfaces are quite different and learning them well enough for this sort of task will take some time unless the user is already CAD proficient. Fusion 360 is free for personal use but it is not freeware. I find Fusion to be the most intuitive of all the major CAD programs and the number of tutorials available online is huge. A distinct advantage for the newcomer.
If you are able to learn a CAD program and AKABAK well enough in a short time then good for you, for anyone else that time is much more significant than leaving a simulation to run in the background or overnight.
https://www.tomshardware.com/reviews/get-windows-10-free-or-cheap,5717.html
Just a heads up for anyone looking to start afresh; the external Sommerfield radiation case for BEM really doesn’t like thin sheets like the setup shown here. There is a compensation algorithm included in Akabak, but it works better if the ‘sheet’ is meshed at a much higher density than would otherwise be necessary.ABEC and AKABAK are suitable to see the effects and model any design whether it is theoretical with the use of pressure boxes or actual when the whole design is meshed with specific driving parameters.
The rest of the images are here
Dutch & Dutch 8c Review | Page 38 | Audio Science Review (ASR) Forum
Reflections, directivity and boundary interference are all within ABEC/AKABAK's BEM capability, COMSOL doesn't really offer more until it's multi physics or FEM are needed and without a commercial application or access to it in another way the price is pretty wild.
Some aspects of this have been discussed elsewhere recently and it is not just the front wall that needs to be considered, the side, floor and ceiling are often more trouble than the front wall alone. Vituix can demonstrate some of this too in a limited way. Like with any speaker absorption and directivity can help.
Dutch & Dutch 8c Review | Page 38 | Audio Science Review (ASR) Forum
Markus had some ideas of on wall in the same thread
Dutch & Dutch 8c Review | Page 39 | Audio Science Review (ASR) Forum
Using an infinite baffle or multiples of those to make a ‘room’ is an easier approach, although you then can’t assign an absorption coefficient to the surface.
Likewise, any ‘thin’ sections internally such as ducts, folds, bends or chambers should be meshed at way higher resolution than the value suggested in the app to get accurate results. If you’re making a small speaker, then approaching the internal volume(s) separately so you can re-mesh at a higher element density can make a significant difference to the results.
As fluid says, if you can ‘think CAD’ then that’s the harder part. Stick to real simple representations of cabinet geometry, and consider how you’ll slice up the model for simulation as early as possible. I tend to draw a solid body, slice appropriately, then unstitch into parts ready for a cleanup pass of deleting unnecessary elements for the simulation. Leaving a square cutout for a baffle element to mount the diaphragm element in Akabak is good too, as it avoids issues with the circular meshed overlapping.
Sadly I’ve had weird results using a real driver model of the cone externally, and setting it to a driven boundary. The bifurcation method of approaching drivers in Akabak does better than Delaunay, and that affects imported geometry. Doing a simple donut for the magnet in CAD is a good idea though, if it’s going to occupy a lot of volume.
Depending on how often you might need the sims run, I can lend some CPU time to the ‘in room’ models and perhaps share the result file. I think the demo of Akabak loads a pre-calculated result file, even if it can’t save new ones? I’ve got two desktop machines, including one with quite a chunky 24-core CPU which didn’t cry too much at being asked to solve a model with 70,000 elements overnight 🙂
True but it didn't affect the observation fields which was the intent for that simulation. The wall could easily have been made to be thicker.
For simulation I model in surfaces, I model the drivers separately with the Diaphragm scripts and export them as STL's to cut the baffle with, so the vertices line up exactly when it's all meshed together
What did you do and how was the result weird? The description isn't making it clear to me.
I run Linux on my end machine, and Windows runs as a Virtual machine. No emulator. VituixCad runs as normal. No performance hit.
Thanks Allen, when I said "windows partition", I was actually thinking of a windows VM. It has been 3 years since I walked away from all of that, and the details get fuzzy.
On my team we did it the other way around. We had to have windows machines for corporate interface/security purposes, so no linux machines... but we ran Cygwin with bash shell. Worked very well for high performance computing.
On my team we did it the other way around. We had to have windows machines for corporate interface/security purposes, so no linux machines... but we ran Cygwin with bash shell. Worked very well for high performance computing.
The problem with free large commercial programs is that they are only free for a while. They are free in order to get users dependent. If one is going to invest substantial time learning to use some software and, more importantly, developing lots of input files that only work with that software then it is fairly important that the software remains usable into the future. Having learnt this the hard way in the 80s I now only generate data that is important to me in a form that will remain usable into the future. Not all data just the important stuff. Similarly I tend to only invest significant time learning software that I will be able to use in the future. I didn't think like this for the first decade or two of significant computer usage but I have for the last few decades. So I will opt for slightly clunky cross platform software over slick commercial programs for particular platforms pretty much everytime.
Thanks that was useful. Windows is still around but expensive when it doesn't come with the hardware.
Weird results are pretty normal when wrestling with new stuff. Most of the time it is us not quite understanding all the relevant details (but sometimes it is bugs). This is my current weird result trying to make sense of acousto (testing the new forum software's image handling!). In gmsh the elements on the driver are in one group while the rest of the elements on the speaker surface are in another. Away from the body the contributions from the driver elements seem as if they may not be being included. Note the lower level diffraction at the speaker edges is present. It is weird and I am going for a coffee.
Yep; I know you know your way around the app very well, but it could catch other folks out so thought it worth mentioning. It’s fine if the volume is enclosed, of course, so possibly another justification for modelling a room rather than one wall. You can always set the other surfaces to be infinitely absorptive to ‘remove them’ from the plots temporarily.
Likewise; when the solid is deconstructed it results in surfaces, which are separated into groups or layers for export as separate STEP files, then imported one by one as ‘physical layers’ into a single Gmsh project for meshing purposes.
I find this approach avoids errors from overlapping elements of edges, which I’ve had when working purely with surfaces. Particularly with import and export between apps, and complex boundary geometries.
Working parametrically from day one is the biggest thing though. Defining edges or sizes via scripts or variables in the CAD app of choice makes things much easier to tweak and refine than drawing via point and click, while also reducing the risk of errors from tiny offsets or overlaps. It can be a real pain in the backside to hunt those down…
I don't think it'll affect this project, but I was modelling a bunch of complex geometries each with multiple diaphragms or drivers in angled placements. It was actually a bunch of models with different array configurations of various horn subwoofers.
I thought it would be easier and more accurate to use a de-featured version of the actual driver's CAD model, which I had from the manufacturer. I was having problems getting the Akabak 'diaphragm' elements to avoid running afoul of the baffle cutouts, or getting the exact angles and sizes right for the 'baffle' elements.
The attempt was to keep only a simple solid for the magnet and coil, and a single surface for each of the front and rear sides of the cones.
Then bringing those in via third party meshing as a tagged layer of the total cabinet mesh, with a high element density, and mark them as the driven surface. This is a method commonly used in COMSOL models, which was the inspiration. Unfortunately, it behaved strangely, despite everything appearing to be much more accurately located and visually more correct. For example, despite being a single tag and surface, the surface area showed up as zero in the lumped element picker for the dynamic driver element.
This has happened since in other cases, but I've also had tags and whole chunks of mesh appear just fine in the drawing tab when importing the mesh file, but just not be selectable or visible when adding elements from the mesh file to a subdomain.
I've had a similar strange set of results when setting 'diaphragm' elements to use Delaunay meshing algorithm in Akabak itself - they end up looking like a pink blob visually rather than a cone, even with a small mesh edge lengths set.
There's a couple of repeatable test cases to send over to the developer so hopefully, these minor things will be resolved in the future.
Until then I'd suggest making sure to manually set Bifurcation as the mesh type on any diaphragm elements if you're using the built-in Delaunay algorithm on the rest. Also, stick to the classic six elements per wavelength guideline for numerical modelling for any sections which could be considered small/narrow/thin or places close to the diaphragm. Interfaces also benefit from a higher mesh density than other boundaries. It shouldn't massively increase the solving time.
This is true, but I have some hope for Fusion because it already went through the cutting back phase for the free version. Due to huge user backlash they reversed their decision to remove step export. I think they learned their lesson that to be a gateway product it still has to be functional.
I understand your point. As this is meant to be a group project you might also want to consider that not everyone will agree with your choice, leaving you to go it alone. All the big solid modelling programs are very similar to each other underneath so skills learned in one are rarely wasted.
I think the sort of model being made will affect this too. I find some parts of cabinets are better meshed together rather than being split, it all depends on how fine the mesh is and whether aligning the vertices is necessary. I've developed a pretty good workflow with surfaces where I design them to have no overlap. All my troubles have come from trying to turn solids into surfaces and missing bits 🙂
One of the old ABEC tricks was to set the edge length very low in the program but mesh in Gmsh at the resolution you wanted, that would stop ABEC from remeshing with it's algorithm and messing things up.
I am working on an on-wall design for the living room anyway and so if nobody else joins in I will have lost little and gained a bit of wisdom.
When developing 3D models via the results from 3D simulations a CAD geometry is a fairly minor component and in some cases not even present if a topology and/or computational grid is the fundamental geometrical entity. What matters most if a CAD package is used is the form of the data that is passed to and from. This determines how well it interacts with the work and data flow as parameters are modified and a 3D design is studied and evolved.
At present (it may change) the geometry is defined via a python script using the gmsh API and opencascade API. The paraview and gmsh GUIs are used as viewers/browsers but one could use other CAD-type programs. It is defined via a script rather than point and click so that the parameters are available to all components in the work flow and not just the CAD GUI. As 3D simulation becomes important and one wants the ability to easily swap out software components it is the natural way to work. For example, yesterday afternoon I swapped out acousto for bempp to help examine/understand issues in acousto's predictions but the geometry, gridding and plotting parts of the work flow remain essentially untouched. That not only helps in terms of not having to redefine things it also helps reliability in knowing that the geometry and grid are the same and differences are arising in the BEM solvers.
Perhaps I should add that efficiently working with sets of large, slow, complex 3D simulation packages some of which are not too reliable (making alternatives useful) is substantially different to working with small and fast 0D/1D simulations which tend to be best handled in a single easy to use package (e.g. virtuixcad).
That is a really powerful way of generating the mesh and there are few people in diy forums who have the skills to do it.
My comments are aimed at average users trying to find simple ways of importing geometry into ABEC/AKABAK.
Please don't become another victim of adding an R into Vituix.