Determine if a M4L device is getting mono or stereo audio
Is there a way to tell if a M4L device is receiving stereo audio?
I know I can do a null-sum check to see if the audio coming from both channels is the same or not, but what I would like to be able to do with that is to set a onebang-style flag where if the audio coming in is mono, I just sum it, process it in mono, and send it out both outputs (to save 50% of the CPU usage by muting the "R" polys), but if it's stereo, then process both channels independently.
I guess there are potential edge cases where the device may have mono audio coming in for a while, then a bit of stereo (or vice versa). In those circumstances I'd just default to once-stereo-always-stereo, just in case.
But yeah, is this a thing?
AFAIK there's nothing implemented natively so I guess your idea is a way to go.
Another option would be tu use a manual mono/stereo input switch.
Hmm, do you know if that processes only one channel's worth of audio, or does it just sum the input?
Ok, I think I've worked out a nice automated way to do this. So far it appears to be working in context, but I'll put it through some more paces.
(this is only the detection part of the patch, there's more than handles some audio routing and poly muting based on what is being detected. plus this is also "dumb" in that once it detects a stereo signal, it stays that way and that's that)
hay,
interesting question... actually i believe it is already the best you can do... to check for dual mono by something like
[-~]
[snapshot~ 200. ]
[change]
and then mix channels & mute the left poly according to the result...
it cant get much easier?
Isn't [edge~] cheaper than [snapshot~]?
I guess in this approach it's a one-way-ticket kind of thing where once it's stereo it never goes back (which works for my purposes). I think it'd be possible to do a dynamic version where there's a thresh (time or otherwise) involved so it can re-default to mono (cheaper) processing.
When trigger only with a bang, [snapshot~] feels quite cheap to me.
You could also decide when you want to test, something along this idea:
Use a volley of bangs if you want, to care for the case when 2 samples would actually have the same value even with a stereo signal.
Ah interesting!
That's simpler, and cheaper looking. It would be a matter of when to bang the [snapshot~]. Startup isn't necessarily a good time, and checking for the presence of a signal probably negates the savings of using scheduler-rate null-summing.
I guess something like this would still be cheaper than the audio rate version:
snapshot is for sure more expensive than egde.
but in max for live you wont be worrying much about scheduler load, isnt it.
i dont think you can completely avoid audio rate to route audio signals based on an audio signals content.
even if you use [send] instead of [gate~] you´re copying a signal vector.