Updated 8x8 and 16x16 audio

Does the xlr board have enough gain for a dynamic mic(SM58)? I’d like to make a mixer for my mom. And use another board for possibly a powered speaker or monitor. So that would only need a balanced and unbalanced input.
 
The XLR board should have *close to* enough gain. The PGAs have 60dB of gain, so a vocalist with a strong voice will be fine, a whisperer not so much!

I haven't yet tested this in practice - the XLR connectors haven't arrived yet!

Most of my mics are condenser, but I have some Behringer XM1800 dynamics so they should do OK for testing even if they're not as sweet as SM58's. I can work out absolute sensitivity using my ECM8000 measuring mic, if I dummy up a phantom powering arrangement.

I'll post the results here and on the repo when they're available.
 
All good news … let’s hope the new boards work as intended!

Took a look at your linked repo, nice job on the documentation. Obviously it’s all a work in progress, but should there be a control driver one too? I was looking at your figures for CPU use, which seem high; this may be because you’re multiplying the AudioProcessorUsageMax result by 100, which is not applicable for the Teensy 4.x library (despite Paul banging on about maintaining backwards compatibility for any changes, he didn’t in this case, and also hasn’t documented it).
 
Jonathan,

Yes, there will be a separate driver repo linked to the hardware one (control_TLV320AIC3104). I'll move the driver doco across to it when it's there.

The mux code is incorporated, as Rob Tillaart's excellent library for the PCA9548 series was far more extensive than was required to control the mux in this instance.

I'm loath to release code until its properly tested on the final hardware.
 
Thank you! Looks very comprehensive and well-commented and documented, so it should be easy to use and figure out if (when) I do something wrong!

I assume the TDM objects are only needed pending Teensyduino 1.60, which should have all the (known) TDM bugs fixed? There’s a few items in there I don’t recognise and may be unused, but that’s to be expected in development code. If changes are needed then I’m happy to roll them into my multi-TDM, if you like, then the eventual TD1.61 can just have that plus your control suite for full support of your hardware.
 
I've uploaded the example files.

The 16-bit DMA-audio buffer data copying may not be required. I wrote it before I found the bug in the 32-bit code. The example files have no argument in the constructor, so I guess the code is unused .. it's been 6 months since I finished work on the driver.

The critical fix is line 105 in the input and the same code in the output. As you say, these should be fixed in 1.60.

I did have some code in there for inverting BCLK, but I intended to remove it if I haven't. I went for hardware inversion, so that the standard (fixed) TDM driver would work OOB.
 
That’s great, I’ll have a nose.

Sounds like early adopters will have plenty of choice for TDM, then: either your fixed one, the TD1.60 beta one, or my multi-TDM one. I also implemented the BCLK inversion in software, I’ll probably leave it in there “just in case” - it’s only a few lines of code.
 
Yes, leave in the BCLK inversion - it will make things easier for other hardware creators. I only removed that feature from my solution as I didn't know if that it would be included in 1.60.

BTW, thanks for the pull request with the fixes. Those typos do love to get through.

I left in the change to AudioProcessorUsage( ), however I seem to get a fractional rather than percentage return value (see the tests in the hardware repo's readme.md) . . . or . . . processor usage is so low that it's barely registering (which would be magnificent)! I'll write something that is heavy on CPU and see. In the meantime, I'm happy to accept that your version is correct.

Interesting that Paul's moved to using Sparkfun as an exclusive hardware wholesaler. I hope that means he'll actually have more time for new products and software. His announcement suggests that's his intention.
 
The CPU load is astonishingly low for the number of channels, isn’t it! I suppose it’s just a bit of memory shuffling then letting DMA do its thing … the shuffling for multiple outputs got a bit mind-bending, though o_O

Yes, the Sparkfun announcement is good news, should free Paul’s creativity :D Though it would also be nice if he could devote a little time to website and repo maintenance, too … it’s all very overgrown and stale at the moment. It’s just about OK for the experienced user, but n00bs are really struggling as far as I can tell.
 
You must log in or register to reply here.
Back
Top