Cascading audio ducking using teensy?

Status
Not open for further replies.
M

mjgtp

Member
I'm a novice in the hardware arena, but a software developer for the last 20 years. I've been kicking around the idea of having an audio mixer that I could use in the bedroom between a TV, music source, and Alexa. I'd like to have Alexa have top audio ducking priority, followed by the tv, then audio source. Basically if i'm listening to music, then turn the TV on, the music would be muted (or just lowered) and i'd hear the TV. If Alexa then chimed in, she would override the TV audio (while overriding the music source). Is there a way to do this with Teensy and a few audio shields?

At the moment, I have a Rolls audio mixer, but it'll only do a single ducking source, while mixing the other two. It's not ideal. (and those things are expensive AND HUGE!!)
 
There certainly should be a way to do this, but since the audio shield is only stereo and Teensy can use at most 2 shields for 4 channels, you'll need at least a couple boards to accomplish this. That will add some complexity in communication between them.

Audio-wise, this ought to be fairly simple. You'd just feed the I2S input to a mixer to control the output level, and also to a RMS analyze object to give you an idea of the signal level. A little fiddling will probably be needed to get the level which is a real signal and not just the noise floor of your system. Then a little code to adjust the gain based on the levels you're reading...
 
Paul, correct me if i'm wrong, but if I understand correctly I'll need 1 teensy, and 2 audio shields (the quad setup) in order to handle 2 stereo input audio sources, with 1 stereo output?

In order to do ducking between 3 devices, I need to duplicate this setup and feed the output of one of these combination setups (teensy+2 audio shields), into a second setup. At least in my head this makes sense. What kind of audio latency would this induce? Anything perceptible?
 
mjgtp said:
Paul, correct me if i'm wrong, but if I understand correctly I'll need 1 teensy, and 2 audio shields (the quad setup) in order to handle 2 stereo input audio sources, with 1 stereo output?

In order to do ducking between 3 devices, I need to duplicate this setup and feed the output of one of these combination setups (teensy+2 audio shields), into a second setup. At least in my head this makes sense. What kind of audio latency would this induce? Anything perceptible?
Click to expand...

I think Paul is saying: to have 3 stereo inputs will require 1 Teensy + 2 Audio Boards and another Teensy with 1 audio board.
 
I would think you would need the 2 audio shields on 2 teensy's to do cascading audio ducking because...

1) You need 2 inputs (2 audio shields) on the first teensy to serve: Audio Source #1, Audio Source #2 (only output the priority audio input)
2) you need 2 inputs (2 audio shields) on the second teensy to serve: Output from 1st teensy, Audio Source #3 (only output the priority audio input)

Scenario: Between TV and Radio inputs -- teensy #1 would favor TV and output the TV audio, muting the Radio... Teensy #1 output is fed into the Teensy #2 input and Alexa audio, for the two sources. Teensy #2 favors the Alexa input and mutes the Teensy #1 input, only outputting audio from Alexa. After audio is not detected for X seconds, default back to the other audio based on priority.... thus cascading down to the lower priority inputs as higher ones are turned off (or audio stops)

Again, this sounds right to me, but I'll defer to those more experienced here. From what I understand, a single audio shield only has 1 stereo input and 1 stereo output right?
 
Yes, each audio shield gives you 1 stereo input and 1 stereo output. Each Teensy can use a maximum of 2 shields.

Regarding latency, you can expect about 7 to 10 ms. Of course, if your code does things which add audio delay, that will add to the 7-10ms.
 
mjgtp said:
I would think you would need the 2 audio shields on 2 teensy's to do cascading audio ducking because...

1) You need 2 inputs (2 audio shields) on the first teensy to serve: Audio Source #1, Audio Source #2 (only output the priority audio input)
2) you need 2 inputs (2 audio shields) on the second teensy to serve: Output from 1st teensy, Audio Source #3 (only output the priority audio input)

Scenario: Between TV and Radio inputs -- teensy #1 would favor TV and output the TV audio, muting the Radio... Teensy #1 output is fed into the Teensy #2 input and Alexa audio, for the two sources. Teensy #2 favors the Alexa input and mutes the Teensy #1 input, only outputting audio from Alexa. After audio is not detected for X seconds, default back to the other audio based on priority.... thus cascading down to the lower priority inputs as higher ones are turned off (or audio stops)

Again, this sounds right to me, but I'll defer to those more experienced here. From what I understand, a single audio shield only has 1 stereo input and 1 stereo output right?
Click to expand...

Doh! You are correct. My mistake.

A high-level diagram would make this topic clear to all.
 
Paul, for this project, given i'm new to the hardware (I have watched a few of your videos), which version teensy would you recommend? -- or are they all about equivalent regarding this project? Are any versions better with the audio shield? -- maybe v3.6 is better for the faster processor (less latency stringing these things together?) ?
 
Unless you're doing very complex analysis (like multiple FFTs or YIN frequency detection plus other stuff) Teensy 3.2 should be plenty. Just getting the data in & out, and doing RMS and/or peak level detection uses hardly any CPU time.

However, the wiring to connect the 2nd audio shield requires soldering a wire from one of the shields to a pad on the bottom side. If you use Teensy 3.5 or 3.6, that wire solders to one of the pins on the outside each, which is quite a bit easier to solder.

Latency is mostly due to the audio buffer block size, plus some fixed delay within the codec chips on the shields. A faster Teensy won't make any difference there. But if you care about the latency, you could try editing AudioStream.h for a smaller block size. Most features in the library will adapt to small blocks. But some, like playing files from SD cards, are hard coded to 128 sample blocks. If you use any of those, changing the block size is incredibly difficult.
 
That's an interesting idea but since you are looking for hardware ideas, I will offer another.

You could have an analog mux feeding one audio shield if needed and one teensy. Your inputs to the audio mux are also wired to regular analog inputs. The cd quality audio will go through the mux to the audio shield. You will also sample all the audio signals with low quality sample rates to determine which channel to select on the mux. You could easily do 8 channels.
 
That's an interesting idea as well -- are you referring to something like this? https://www.sparkfun.com/products/9056 ? -- I would think though that I would need two of those -- one to iterate through all the channels on a loop to scan for the right prioritized source, and the second to actually pipe the sound of the correct source. Does that sound right?

To sample the audio, I would still need that second audio shield right? One for the sampling to find the source, and one to handle the current source?

That idea really sounds good since the previous design would only support 3 sources, and this would support 8. Not bad for another $10!
 
Oh, hold on. How would something like that work? If it's like that sparkfun item, that's 16 individual channels... if only one is selectable at any given time, that would mean I could only have the left or right channel (not both) being piped into the audio shield right?

In that case, it seems a better solution is 3, 8 channel boards (something like this: https://www.sparkfun.com/products/13906) then...

Board #1, 8 left channels
Board #2, 8 right channels
Board #3, use to scan for prioritized sources...

Does that sound right?

Man, this gets complicated quick LOL
 
You could use 3 as you say. I was thinking two for left and right. Then say all the left channels would also be wired to regular analog inputs and you would sample those to see what devices were active. At $2 a piece it wouldn't cost much to try out either idea.
 
The not very good way to make this work would be relays, with a single teensy using the analog in method to measure RMS of the three/six signals and setting relays appropriately. This will pop and crack during the relay switching and be rather abusive to the three sources so using a mixer would be a much better way to do things.

Other option if you want to get clever is to use a fixed mixer and have the teensy control the other devices to mute their own output, say using IR remote libraries. Though unsure which ways to mute an Amazon device would work for this.
 
I know this thread is a few years old but I have a question. I'm looking at doing something similar to this. Was the Rev D audio adapter available when this thread was started? Is there any advantage to using a Rev C or Rev D audio adapter? You said in this thread that the faster teensy has little to do with latency, but there must be a reason why the Rev D was developed.
 
Yes, Rev C and Rev D are the exact same circuitry. Only the Teensy pins where the I2S signals connect are changed, because Teensy 4.x has them in different locations than Teensy 3.x.

This is explained on the project page:

https://www.pjrc.com/store/teensy3_audio.html

"In September 2019, Rev D was created for Teensy 4.0. The circuitry is the same as Rev C, but the I2S digital audio signals and SPI signals for the SD card are routed to the pins Teensy 4.0 uses. "
Click to expand...

On the product page you can see the schematics for both. If you compare them side-by-side, it's easy to see they are exactly the same, except the Teensy pin numbers where the signals connect to Teensy.


but there must be a reason why the Rev D was developed.
Click to expand...

Yes. The reason is simple. The new chips on Teensy 4 have their I2S signals on different pins than the older generation of chips used on Teensy 3. It's really that simple.


FWIW, the change from Rev B to Rev C was adding just one 100 ohm resistor. Otherwise they're exactly the same.
 
Status
Not open for further replies.
Back
Top