Hi all,

this feels like a trivial problem, but I can't get my head around it.
I've got an electret mic connected to the analogIn of an arduino rp2040 connect. I'm sending the analogIn values via WiFi over UDP as OSC. I get the data in Pd and I would like to "reconstitute" the mic sound from the analog reading.

I'm familiar with how ADC works, but either I'm stupid or there's something I'm missing and I can't figure out how to go about this in Pd.

Some details:

• the mic output goes through a breakoutboard amp, so the signal arriving into the arduino is already DC Offset and centered nicely between 0 and 1023
• the signal is handled in Pd with a sampling rate of 500hz (according to my measurement), which should be fine for the low frequency sound I'm producing into the mic (sounds won't be higher than 40Hz)
• why I don't simply use a wireless audio transmitter? it's a long story, but this relates to making my long-running XTH Sense biosensor wireless. In the past years I tried many different options to no avail (including making a startup and producing a custom wireless audio hardware), and I came to the conclusion that the project needs the simplest and more reliable ever implementations, if others are really to continue use it.

Any hint is greatly appreciated!
thank you,

M

Hello, here's an update, this is where I am at:

Method #1 with sig~ and lop~ @whale-av

• this works now quite well now. A lop~ at 40 actually hits a sweet spot for the kind of sounds I need to pick up with the mic. Not sure why though. The resulting output is still a bit "noisy", but works well with my patches for the standard XTH Sense, where I use the same mic, but wired. So, this is very good.

Method #2 with tabread4~ @jameslo

• I didn't manage to make it work merely because I didn't understood it fully, not because of the method per se, which looks sound. I didn't put too much work on this, since method #3 seems to be an extension of this, so I focused on the latter.

Method #3 with tabread4~ and vline~ @manuels

• This works well in my patch above, but strangely enough the upsampled signal still presents the steep steps. The output signal sounds as the output from sig~ from method #1. So here I may have missed something in the implementation? or perhaps is the lack of timestamp...

Updates on other solutions we discussed:

• timestamp: I did manage to get a timestamp using the millis() function, which I think should be enough for this use case. This simply counts ms passed from the moment the board has been switched on and attaches it to each reading

• Increasing the sampling rate on the arduino rp2040 with the microcontroller of the same name seems pretty unexplored (at least after one day of investigation on forums etc..). I need to look more into it. But considering what David pointed out about the brickwall at 689Hz, maybe this is not even an option here.
• FYI, on ARM microcontrollers it is possible to use prescalers, bypass analogRead and read analog data directly from the hardware using register calls at quite fast rates (some people managed to almost 40.000). But I chose the rp2040 for its dimensions, its wifi connectivity (and, partially, for the onboard machine learning features). So if anyone knows of another off-the-shelf board that uses ARM and has similar dimensions and connectivity, please point it to me I'll check too of course.

Next steps:

• as it stands, method #1 works well with my patches too and I could just lay back and test this further with my performance software. Especially since by applying the audio signal conditioning and processing I have in my software, the difference with the wired signal is not seriously noticeable and the wireless is even more responsive and less prone to artifacts
• BUT! I would really like to get the upsampling work since it is potentially the most technically sound solution. So I would like now to work more on this using vline~ with the timestamp. A pointer in that direction would be great, since admittedly arrays and tabreads are one of my weak spot in Pd.

P.S. A clarification, before I stated 40Hz as the max. frequency I need to capture, but, to be precise, the range of muscle sounds (including heartbeat and blood flow) is between 1-25/30Hz, as you can see from this pic (a magnitude spectra of the output signal from lop~ capturing a forearm contraction)

@jameslo I think you understood everything correctly! I think David and I were just trying to clarify the problem in that early post.

@MarcoDonnarumma Sorry, I should have explained ... So the "samplerate" should be that of the incoming data, 500 Hz or whatever it might be. And [tabread4~] will then convert to Pd's standard samplerate. Maybe there is even a way to drop the metro and use the incoming data as a clock, but I'm not sure if this can possibly work without timestamp. Good luck and thanks for sharing your efforts with us!

@MarcoDonnarumma I'm so grateful for this interesting problem because I'm isolating with Covid far from home . Here's a simulation of the Arduino with a slightly different clock speed, sample jitter and irregular transmission intervals. The Pd patch uses a 95 sample circular buffer and arranges for the playback point to dynamically chase the insertion point. See what you think.
bufferedResamplerTest.pd

PS: I'm not following the discussion about timestamps and vline~. As long as the Arduino's sample jitter is low enough and no data is lost in transmission, can't we just assume that the data is coming in order and plop it into a circular buffer?

@MarcoDonnarumma The jitter seems unpredictable in your data.... so...
Trying to put the samples at the correct time...... and keep the patch simple with as little delay as possible..... (If only because I don't have the expertise of @jameslo and @manuels).
I am much more comfortable at control rate.......

The timings from the arduino are not really accurate enough but they will help to massively decrease the jitter.
The [lop~] value can probably be increased as [vline~] will create ramps between samples rather than steps.
If you can send more accurate timings it will improve without changes to the patch...... i.e 231.445.

But beware that as the ms timing values get bigger all the time they will become less accurate in the osc and probably hit the Pd limit for representation........ sorry I didn't think of that before.
So it would be better to send the time difference between samples so that the values stay within range...... with the added bonus that my patch would then only contain 8 objects including [udpreceive] and the [dac~]......

I cannot connect it properly as I don't have [scale.lin] but here it is......
timing.pd

Please don't laugh.
David.

P.S. If the results are worse than your previous test with [lop~] it is because the arrival of the osc messages is better timed than the sample time stamps that the arduino is sending.

@jameslo That's bad luck...... the Covid. I hope it's not too bad.
David.

@whale-av Thanks, it's a huge costly annoyance for sure, but not nearly as scary now as it was pre-vaccine.

As an alternative to [lop~] in method #1 you could also use [slop~] ... just came to my mind.
Edit: Hm, I don't know ... But you should definately try a higher-order filter like [butterworth3~] in the Pd audio examples! It will do a much better job removing high frequencies.

hey @whale-av @manuels @jameslo thanks once again for the feedback! I think we are getting there, very exciting. I just quickly plugged your suggestion into my patches and they both work well. Interestingly enough now the sig~ and the resampling method result in two sounds that are timbrically quite different, but still coherent with what I would expect. This is super interesting, even as a creative toolset, as long as the difference in timbre are not artefacts. I will investigate this further and try to post some audio examples.

Gonna work more on the project this week and keep you posted. Just bear with me as I cannot work on this full-on every day like the past weekend, cause of other commitments.

@jameslo sorry to hear, it is quite jumping around these days, I hope your symptoms are bearable, and I'm glad that an interesting problem can help a little

@whale-av the vline~ there is very elegant! I had previously tried with a line3 in the control domain but your suggestions makes more sense. I've used a bucket object to get the interval, that should be the same as what you are doing in your patch.

@manuels yes, indeed. Different filters are the next thing I'm gonna look into, especially as I gonna need a more systematic spectral analysis of the resulting sound to make sure it is still coherent with the expected signal.