This is really cool! I’ve heard of both A2B and Sigma DSP before being used by recording and mastering engineers. A2B is like the next I2C but for multichannel audio (in fact it actually includes I2C as part of its spec). You can use these buses for doing all sorts of crazy acoustics stuff in cars like noise canceling the road noise picked up by the MEMS mics or even Spatial Audio applications to give each passenger a personalized audio experience. Analog devices also has an interesting video where they demo this technology by building an audio mixer, similar to one you might see in a recording studio, with the sigma DSP chip. I think you may have inspired me to get one of these to fiddle around with in my car or home theater 😆!
I also looked in this direction and realized that tube sound cannot be realized using conventional conversion modules. Full models of the components and calculation of the circuit operation are required; all that is required is a powerful PC processor.
My experience from working with DSP development for a couple of years is that you eventually just have to give in and use the work flow suggested by the vendor, however archaic that may be. I prefer working in Linux but I had to give up and use Windows with these bloated vendor IDEs in the end. Analog devices was notoriously bad, but the other vendor were pretty crappy too :P Their hardware was really good though.
I went down the dev nightmare rabbit hole for these dev boards when you made the other video... Its frustrating how little documentation is available. It seems like very few people know how the whole dev to prod process is supposed to go with these. Im all for trying new stuff but these boards are crazy expensive in my country. Looking forward to more videos on this topic!
FWIW, the most important thing when handling is to touch off first to a chassis ground like a USB connector shell or an Ethernet port shield. Once you’re equalized to chassis ground (any reasonably designed PCB should be immune to ESD there) it’s generally ok to touch it anywhere. Just stay in contact with the ground most of the time while handling. The worst thing to do is to walk up to a PCB, grab it by the edges (for example) and arc off to a random part or trace.
We've worked with exactly the 589 (for image processing). Bottom line was that a decently recent ARM processor with Neon extension can do the same computation, but is much more accessible in terms of development tools.
That was a tough undertaking, which is why I prefer to stay away from a lot of software installations. In the mid-2000s there was a German 19 inch module called Creamware NOAH that's based on several SHARC DSPS & was award-winning by its algorithms. I don't know if this expander made it to the US. Those algos were then used to produce nice looking , polyphonic desktop so called ASB (authentic sound box) clones with all the original's controls, that unfortunately suffered from teething problems and sometimes even aliasing (instead of NOAH). Minimax ASB sounded best. It didn't aliase at all. The PRO-12 ASB had some aliasing (in hard sync mode) & a darker sound than a real Prophet-5. The (to me) hottest one - Prodyssey ASB aliased comparably strong when hardsyncing but had a selectable minimax beside its ARP LPF. There was also an organ module with drawbars called B4000 ASB, all of them SHARC based with a high fun factor despite some limitations.
Kernel drivers don't run under emulation, only applications do. If you don't have an Arm64 native driver, it will not work. Ask Analog Devices (assuming the driver(s) came from them) to support Arm64 with their custom drivers.
I thought about that, but according to some other responses here the device drivers really need to be ARM native and they just won't work through any emulation. I still might try it if I find some time.
I suppose you could run Remote Desktop from your good machine to the windows one. The problem being of course, either the need for VERY long cables, or not being able to access the hardware easily.
Is the Win10 machine used regularly downstairs? If not, I would just move the CPU upstairs and access it remotely from the MAC. I do something similar - I have a headless linux machine next to my W10 machine and pretty much just use it just for compiling and sending the code to Arduino's/ESP32s. For whatever reason, in Windows, it can take 2 min to compile and send a program, but in Linux it takes 10 seconds. I think it has to do with antivirus, but I have never been able to fix it on the W10. Good luck!
Camera SoCs are dirt cheap nowadays and can do much more. Like running a real OS and handle peripherals in real time. RV1126 and is siblings are a good example.
Looks like there's a Linux version published. Perhaps THAT would be a better idea? I don't remember having to restart 5 times for a driver installation.
@@Lantertronics I imagine you might have some kind of pink panther/Kato arrangement where she attempts assassination every time you come home to keep you on your toes ;)
You can find my e-mail address pretty easily by google searching my name. I do get a lot of e-mail though and often fall behind, so don't take offense it if takes me a while to write back.
it looks like there is an ubuntu version, maybe you'd have more luck with that, no idea if you'd be able to run that directly in osx but probably not, but either a vm or running directly might be ok (live version on an external drive for instance), driver problems notwithstanding
@@Lantertronics there was that brew package for running Linux stuff on osx, but I imagine this is a single binary rather than making use of open source libraries etc
As OS X evolves, the Security features screw down tighter all of the time, making it difficult to do anything that could possibly allow any kind of back-door attacks. As a result, things get gnarly when trying to do anything Windows related, especially when you are trying to get USB drivers that rely on interrupts and low-level device drivers. Parallels cannot handle that realtime OS stuff; it was mode to run more generic apps like spreadsheets, etc. So, my advice is to forget trying to run this on OS X, especially on ARM machines. I now that's not the answer you want, but I've lost so much hair over things like this that IMHO it is not worth it. Note that trying to get support from Analog Devices on this issue will prove fruitless. The engineering development world has classically centered around using PCs running Windows and that is especially true for Analog Devices as well as NXP and STM dev kits. Al of the hands-on seminars I've attended specifically state to bring a Windows machine. Even with that requirement there have been issues getting apps & drivers setup properly, depending on what version of Windows and what updates have or have not been installed on a particular PC. My advice is to get a cheap Win11 laptop, or get a used Intel MB Pro that you can install boot camp on. Good luck!
This is really cool! I’ve heard of both A2B and Sigma DSP before being used by recording and mastering engineers. A2B is like the next I2C but for multichannel audio (in fact it actually includes I2C as part of its spec). You can use these buses for doing all sorts of crazy acoustics stuff in cars like noise canceling the road noise picked up by the MEMS mics or even Spatial Audio applications to give each passenger a personalized audio experience. Analog devices also has an interesting video where they demo this technology by building an audio mixer, similar to one you might see in a recording studio, with the sigma DSP chip. I think you may have inspired me to get one of these to fiddle around with in my car or home theater 😆!
i remember getting SHARC dev boards in a college class eons ago. super fun to play with. PS - you thought you owned your computer.. bwwwaahahaaha
I also looked in this direction and realized that tube sound cannot be realized using conventional conversion modules. Full models of the components and calculation of the circuit operation are required; all that is required is a powerful PC processor.
My experience from working with DSP development for a couple of years is that you eventually just have to give in and use the work flow suggested by the vendor, however archaic that may be. I prefer working in Linux but I had to give up and use Windows with these bloated vendor IDEs in the end. Analog devices was notoriously bad, but the other vendor were pretty crappy too :P
Their hardware was really good though.
I went down the dev nightmare rabbit hole for these dev boards when you made the other video... Its frustrating how little documentation is available. It seems like very few people know how the whole dev to prod process is supposed to go with these.
Im all for trying new stuff but these boards are crazy expensive in my country.
Looking forward to more videos on this topic!
FWIW, the most important thing when handling is to touch off first to a chassis ground like a USB connector shell or an Ethernet port shield.
Once you’re equalized to chassis ground (any reasonably designed PCB should be immune to ESD there) it’s generally ok to touch it anywhere. Just stay in contact with the ground most of the time while handling.
The worst thing to do is to walk up to a PCB, grab it by the edges (for example) and arc off to a random part or trace.
Shark nice dsp chips 😊
We've worked with exactly the 589 (for image processing). Bottom line was that a decently recent ARM processor with Neon extension can do the same computation, but is much more accessible in terms of development tools.
9:16 I'm experiencing some Powershell PTSD.
12:53 My smart-ass answer is "take the windows machine upstairs". YMMV.
:)
That was a tough undertaking, which is why I prefer to stay away from a lot of software installations.
In the mid-2000s there was a German 19 inch module called Creamware NOAH that's based on several SHARC DSPS & was award-winning by its algorithms. I don't know if this expander made it to the US.
Those algos were then used to produce nice looking , polyphonic desktop so called ASB (authentic sound box) clones with all the original's controls, that unfortunately suffered from teething problems and sometimes even aliasing (instead of NOAH). Minimax ASB sounded best. It didn't aliase at all. The PRO-12 ASB had some aliasing (in hard sync mode) & a darker sound than a real Prophet-5.
The (to me) hottest one - Prodyssey ASB aliased comparably strong when hardsyncing but had a selectable minimax beside its ARP LPF. There was also an organ module with drawbars called B4000 ASB, all of them SHARC based with a high fun factor despite some limitations.
Kernel drivers don't run under emulation, only applications do. If you don't have an Arm64 native driver, it will not work. Ask Analog Devices (assuming the driver(s) came from them) to support Arm64 with their custom drivers.
Hi Aaron, how is about running UTM QEMU with a proper x86 emulation and x16 Win10/11? it's not that efficient, but at least it's running on M macs. .
I thought about that, but according to some other responses here the device drivers really need to be ARM native and they just won't work through any emulation. I still might try it if I find some time.
I suppose you could run Remote Desktop from your good machine to the windows one. The problem being of course, either the need for VERY long cables, or not being able to access the hardware easily.
Yeah, you really want everything in one spot.
Is the Win10 machine used regularly downstairs? If not, I would just move the CPU upstairs and access it remotely from the MAC. I do something similar - I have a headless linux machine next to my W10 machine and pretty much just use it just for compiling and sending the code to Arduino's/ESP32s. For whatever reason, in Windows, it can take 2 min to compile and send a program, but in Linux it takes 10 seconds. I think it has to do with antivirus, but I have never been able to fix it on the W10. Good luck!
@@justinahrens1868 It's primarily used by my son, so we like to have it downstairs.
Camera SoCs are dirt cheap nowadays and can do much more. Like running a real OS and handle peripherals in real time. RV1126 and is siblings are a good example.
But not made for audio processing…
@@JudgeFredd Do your homework.
@@lambdaprog www.rock-chips.com/uploads/pdf/2022.8.26/192/RV1126%20Brief%20Datasheet.pdf
Looks like there's a Linux version published. Perhaps THAT would be a better idea? I don't remember having to restart 5 times for a driver installation.
Ah, interesting idea! I will explore.
the sword of damocles at 2:28 there, dave rossum has a suit of armour in his house for some reason
That (and the various other swords and daggers in my house) all belong to my wife. :)
@@Lantertronics I imagine you might have some kind of pink panther/Kato arrangement where she attempts assassination every time you come home to keep you on your toes ;)
I have a question unrelated to this video. What’s the best way to get in contact with you?
You can find my e-mail address pretty easily by google searching my name. I do get a lot of e-mail though and often fall behind, so don't take offense it if takes me a while to write back.
Nice dagger
Belongs to my wife (along with a variety of other daggers and swords!)
could wine work maybe?
No, alas. Wine doesn't actually emulate the Intel CPU itself the way Windows for ARM does -- it needs to have a Windows CPU.
it looks like there is an ubuntu version, maybe you'd have more luck with that, no idea if you'd be able to run that directly in osx but probably not, but either a vm or running directly might be ok (live version on an external drive for instance), driver problems notwithstanding
I'm going to check that out...
@@Lantertronics there was that brew package for running Linux stuff on osx, but I imagine this is a single binary rather than making use of open source libraries etc
Maybe Network usb hub and rdp
As OS X evolves, the Security features screw down tighter all of the time, making it difficult to do anything that could possibly allow any kind of back-door attacks. As a result, things get gnarly when trying to do anything Windows related, especially when you are trying to get USB drivers that rely on interrupts and low-level device drivers. Parallels cannot handle that realtime OS stuff; it was mode to run more generic apps like spreadsheets, etc.
So, my advice is to forget trying to run this on OS X, especially on ARM machines. I now that's not the answer you want, but I've lost so much hair over things like this that IMHO it is not worth it. Note that trying to get support from Analog Devices on this issue will prove fruitless.
The engineering development world has classically centered around using PCs running Windows and that is especially true for Analog Devices as well as NXP and STM dev kits. Al of the hands-on seminars I've attended specifically state to bring a Windows machine. Even with that requirement there have been issues getting apps & drivers setup properly, depending on what version of Windows and what updates have or have not been installed on a particular PC. My advice is to get a cheap Win11 laptop, or get a used Intel MB Pro that you can install boot camp on.
Good luck!
Its a shame when bad development tools happen to good parts
Truth!