BeepWAV example but mono?

[RandomHacks-Git]

I have a PCB with an RP2040 that uses pin 0 as an enable for an amplifier and pin 1 as the audio source.

I tried the PWMAudio example "PlayRaw" included in the core and it worked fine, I then tried the "BeepWAV" example from this BackgroundAudio library and it did not work.

I suspect that "PWMAudio pwm(1);" in this example doesn't behave like stated in the core's documentation and instead behaves like PWMAudio pwm(1, true) which in turn doesn't output anything as it expects an even pin, I tried pin 0 and verified with an oscilloscope that I get an output on both pin 0 and pin 1.

Is there a way to play mono audio on an odd pin with this library?

[RandomHacks-Git]

Ah, the sooner I had opened this issue, the sooner I would have discovered the solution...

pwm.setStereo(false) did the trick

Still confusing though, would be nicer if it behaved like the the PWMAudio library

EDIT: Nevermind, I still had the pin set as 0 and somehow it manages to output the beep using the enable pin of the amplifier ic, electronics are weird sometimes... The issue persists when I set the pin to 1.

[DanEfran]

I believe I can confirm this. I just tested a fresh copy of BeepWAV, changing only the PWMAudio pwm(...); line.

PWMAudio pwm(0, false); seems to give the same stereo output as PWMAudio pwm(0, true); on pins 0 and 1. The documentation suggests pin 1 should fall silent but it doesn't seem to.

PWMAudio pwm(1, false); seems to fail, just as PWMAudio pwm(1, true); does (and should). It does not seem to produce mono output on one pin as the documentation suggests.

[earlephilhower]

This is by design. The codecs enable stereo mode as part of the decoder begin.

The reason for this library versus Esp8266audio is to simplify things here so they can run fast and standardized. Fewer options, but way less overhead per sample.

If you'd like to throw together a PR that implement mono downmixing (I think the gain routine would be the right spot as you can fold it into the scaling, and adding a setMono option to the 3 decoders) I'd be happy to look at it.

[RandomHacks-Git]

Ah, that is a bit of a caveat. It doesn't really affect me, as I just happen to have a board with an amplifier connected to a pin and decided to test this on that. However, I can certainly imagine that some people might design a board expecting mono to work on just one pin, only to find out the hard way that it does not, especially if they choose an odd pin.

At this point, if someone needs mono, the solution is to use an even pin and leave the next pin unconnected.

I had a look at the source code before opening this issue, but it is a bit over my head. Your explanation alone about where mono could be implemented made me a little dizzy, I’m more of a hardware guy 😅

Thanks for replying.

[DanEfran]

I agree that the current workaround is to use an even pin and waste the next pin. I don't love that.

I think I'll take a look at putting together a PR for this. It should only be about a dozen lines of code, I think.

The only question is the "mono downmixing" technique. There are more complex ideas--which are probably still pretty simple math, but with more chances to get it wrong--but I'm inclined to simply omit one channel or the other--user-selectable, perhaps. That's a simple approach, and it's not wrong. (The user can always provide their audio data pre-downmixed to that channel however they want it.)

[RandomHacks-Git]

Yeah I believe omitting one channel is suitable for most use cases, and even more so if there is a way to select which one to use/omit.

It certainly would be a lot better than the current workaround of wasting a pin.

[DanEfran]

On further reflection (and some research to confirm) I don't think there's a better method that's always suitable. Creating a good mono mix is a nontrivial process, requiring aesthetic judgement and a variety of techniques; just mechanically merging the channels is likely to cause problems for some audio data.

(For example, you might try adding the channels together (then normalizing back into range) but suppose the right channel happens to be exactly the same as the left channel but inverted (waveform flipped vertically). Each channel would sound fine alone, but summed they'd produce total silence! This kind of problem is not confined to such contrived examples.)

[earlephilhower]

FWIW, sum-difference encoding has been used to allow mono playback of stereo recordings in lots of things. Instead of storing A and B channels, they store the sum (A+B) and difference (A-B) as the 2 channels. Mono players would read the first track and play that as-is, while stereo decoders would physically read both tracks and use opamps/etc. to convert L=((A+B) + (A-B) )/2 = A, R=((A+B) - (A-B))/2 = B. So summing is perfectly fine. It's what physically you do when listening to stereo with only 1 ear. If they encode a 180 degree phase shift in left and right channels at their own peril. 😆

The other thing I think you'll need to do is adjust the final write size. The data into the gain function is stereo 16-bit, so 2 * framesize * sizeof(16bit). The output for stereo playback in PWMAudio would need to be packed into 1 * framesize * sizeof(16bit). The gain would write to i/2 and the _out-->write will need to be framelen / 2 as well...

[DanEfran]

So summing is perfectly fine. It's what physically you do when listening to stereo with only 1 ear. If they encode a 180 degree phase shift in left and right channels at their own peril.

I see your point, but I think you're being a little too kind to this method. The 180 degree phase shift is a contrived example, as I said, but it reveals a kind of problem that can happen in smaller doses in more normal audio.

Yes, you can hear similar problems if you listen to stereo speakers with just one ear and stand in a spot where there's particularly unpleasant interference between the channels; but speakers aren't point sources and ears can move, so it's not as severe. You're not likely to find the perfect spot to hear total silence. (Even so, there's lots of advice about where not to sit between your speakers, for approximately this reason.) Summing the channels digitally locks that one ear into a particular spot, for good or ill, with per-sample accuracy. A summed mono mix may indeed be "fine" for general use, but without that second channel to reconstruct the stereo, it's an inherently problematic mixdown to some degree.

By picking just one channel or the other, you're only getting half the sound data, but it's always the same half; it sounds like that half was meant to sound. With summing, you're discarding some sound data, but haphazardly, not smoothly. You're capturing both halves, not just one; but you're also altering the sound -- most dramatically in the 180 degree test, but in general too. Yes, it's usually subtle, maybe even inaudible, but there's really no guarantee. You could get unlucky at any time, especially with synthetic sound data where an exact phase shift isn't so farfetched. Granted, most of the time it'll be "fine", but I wouldn't say "perfectly fine."

Also, I can imagine scenarios when a user might want to pick a particular channel to play, for less straightforward reasons than simple mono mixdown. Like hey, you could pack two mono sounds into one stereo file...play the left channel, then switch and play the right channel. Or maybe someone wants to have the second channel playing on a separate device across the room, synchronized somehow. Or playing from the second core maybe, on a non-contiguous pin maybe (for whatever reason--perhaps to vary the L/R gain separately?).

Unusual and contrived examples certainly; perhaps not useful ones--but the point is that I can see room for project-specific creativity here. Who knows where it might lead?

Meanwhile, with summing, it either sounds like it should--usually--or maybe it sounds a bit off, or more than a bit off if you're unlucky. Most of the time it works well enough. But none of those creative channel-management choices are available to you.

It does have a more plug-and-play flavor, for what that's worth: the user with a random stereo file they want to play in mono doesn't have to worry about which channel to play, because they don't have a choice. It's always "both, more or less". Put another way, the choices are just "stereo or mono" with no further complications. It's a smaller change to the API, and maybe easier to understand for beginners. If you had, say, voice on the left and music on the right--or dueling guitars--summing keeps both audible, which may be what the typical user expects or wants, while losing one whole side of the content might be a surprising result. But I think the surprise would be short-lived, since they're asking for mono output after all. Contrariwise, what if the user wants exactly this option of playing just the voice without the music? Or Squeedly without Meedly? (While retaining the option to play them together in stereo, since it's still one file.)

(And if you know you're going to use mono output for your stereo sound, you can always just make the exact mono mix you want--whether summed or something more sophisticated--when creating your sound data file.)

So I'm not at all convinced that summing is the best method.

All that said...it's probably good enough for general use, if you really prefer it.

Perhaps the best option is to support both methods, by offering four modes: Stereo, Mono L, Mono R, Mono R+L. Perhaps that's overkill, but it would satisfy everyone and it wouldn't be much more code. (A few extra lines, essentially muting one summing input or the other as needed.)

I'll take a look at the code when I get a chance. It might be a week or two, or more. I think this would be very little code to write, but it's a lot of code to read first, to get it right. (And I don't need that last pin just yet....)