Feature: DSP option: mix chanels

[jagjordi]

I want to suggest an option for the DSP processor. I am using this for a multi-room audio setup and in some rooms I have a single speaker. It would be very good to be able to merge both left and right channels so that the speaker works as a MONO.
Right now I am using a simple DAC plus a separate audio amplifier. So what I am doing is that I am joining both audio channels after the DAC with a simple two resistor circuit. I am thinking to creating a new board that uses one of the amplifiers with a built-in DAC. For that setup, it would not be possible to merge the two channels after they have been amplified. Without having to use big and expensive power resistors, This is why I think it would be a very nice option to be able to do this merging of the channels in the digital domain on the DSP

[CarlosDerSeher]

Shouldn't be too hard. Mixing PCM samples is as simple as adding two samples, L+R. The question is, how we should handle int16_t over and underflows. Just simple clipping maybe?

[normanalie]

Some DACs offer an option to sum the L+R audio channels.
However, if you'd prefer to handle it DSP side, the approach taken by professional audio consoles is typically either a true L+R summing - where if the same signal is present in both L and R, the resulting sum will be 6dB louder - or an L+R-6dB summing, which maintains the same signal level as the original sources.
For this use case, I think L+R-6dB would be the best approach, as we're not aiming for a real summation but rather to create a mono signal that retains maximum information in a single-speaker setup.

[jagjordi]

Why not divide the signal by2 before summing? (out=L>>2 + R>>2) That's what a two resistor circuit does.

…

________________________________ From: Norman Alié ***@***.***> Sent: Monday, November 4, 2024 7:11:50 AM To: CarlosDerSeher/snapclient ***@***.***> Cc: Jordi Altayó ***@***.***>; Author ***@***.***> Subject: Re: [CarlosDerSeher/snapclient] Feature: DSP option: mix chanels (Issue #106) Some DACs offer an option to sum the L+R audio channels. However, if you'd prefer to handle it DSP side, the approach taken by professional audio consoles is typically either a true L+R summing - where if the same signal is present in both L and R, the resulting sum will be 6dB louder - or an L+R-6dB summing, which maintains the same signal level as the original sources. For this use case, I think L+R-6dB would be the best approach, as we're not aiming for a real summation but rather to create a mono signal that retains maximum information in a single-speaker setup. — Reply to this email directly, view it on GitHub<#106 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADLIJK6AK5Z6WBDFTJZOYH3Z64F2NAVCNFSM6AAAAABRC3NYPSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJTHA4TCOJTHA>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[CarlosDerSeher]

Why not divide the signal by2 before summing?

You'll lose a lot of information that way, especially if there are low volume parts in one channel. Also it won't be necessary most of the time. Altough this will definitly be the easiest and fastest approach to implement I guess. Maybe we should convert to float before reducing gain?

true L+R summing - where if the same signal is present in both L and R, the resulting sum will be 6dB louder - or an L+R-6dB summing, which maintains the same signal level as the original sources.

As I am no audio expert, how do you do this implementation wise? Using some FIR / IIR filter structure. How do you analyze the audo sample before summing them? Is this done in the frequncy or time domain?

[CarlosDerSeher]

After giving it another thought wouldn't it be best to just sum L+R using an int32, then divide it by 2 and cast back to int16? So int16_t out = ((int32_t)L + (int32_t)R) >> 1

[jagjordi]

2 things:

For the addition I am more in favor of doing the /2 mix because the "perceived loudness" would be correct. If you add without dividing then you are amplifiying by a factor of 2.

For the implementation, I don;t know much about how the low level implementation on the ESP platform but if you divide by 2 before adding you dont need to cast to int32. A int16 divided by two has a maximum range of 15 bits, so when you add 2 of them the maximum range is 16 bit again. There is no possibility of overflow. you can also implement the /2 by right shifting 2. the >> operator should perform arithmetic shift (preserving the sign bit) when it shifts a signed number

[CarlosDerSeher]

Watch out! x/2 == x >> 1

[DerPicknicker]

Maybe for some of you are interested in real DSP hardware. The TAS5805M DAC has a DSP builtin.

The board designer of those boards enabled the DSP features for snapcast see here: https://sonocotta.github.io/esparagus-snapclient/