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

@MarcoDonnarumma I don't really understand your discussion with David, so I'll just respond as though I understood your first post

Assuming your 500hz sample rate on the Arduino is accurate and jitter-free enough (which is totally doable in my experience), it seems like your only problems on the Pd side are to do the sample rate conversion from 500 to 44100, and to rescale/recenter the samples. The latter is easy. For the former, I'd just fill an array with the rescaled sample data in the sequence you receive it in, and then [tabread4~] the array with a scaled phasor that reflects the sample rate change. I think you can ignore aliasing since you are upsampling.

With no sample rate conversion and a 64 sample array, you'd want your phasor frequency to be 44100/64, so for 500hz you'd want 500/64. If that works then your next problem is working out the buffering so that you can be receiving new data while playing out older data (assuming that your system needs to do this in realtime and can stand a buffer or more of latency).

(BTW, if you can see what I'm not understanding, please let me know!)

Edit: like this (but too lazy to work out the correct padding) resampling.pd

@MarcoDonnarumma Just had a cursory look at you video.... very good.
So you will understand more musical tech terms.
With your low sample rate the steps in the waveform are massive. The result is approximately what you would ask of a "fuzz" box.

Your ears only hear the rapid changes where the waveform rises or falls vertically. Your brain can only interpret the audio that way as it gets no intermediate information.

A rapid rise or fall like those you see in the scope are..... because the signal rate is now (after [sig~] ) 44100 samples per second..... actually a very high frequency signal....... one half (the left or right half) of a 22KHz "note".
Usually called "aliasing"...... they are there because there was no information before or after to give the real analogue slope of the wave before it was sampled.

For CD audio the rate is also 44100Hz. The Nyquist is 22050Hz and a low pass filter in the DAC removes everything above 20000Hz so as to remove such artefacts.

Putting a [lop] will smooth out those steps and approximate the original waveform as it was originally sampled. The downside is that you will no longer hear the audio because it is likely outside the range of most peoples hearing (in this case only!.... with audio below 40Hz..... if it was a 200Hz note you would hear it).

If you put a [lop~] (between [sig~] and [dac~] with a fader connected to its right inlet with a range of say 0.3 to 40 you can play with the fader to get an audible signal that is close to what you want to hear.
A sort of "depth of fuzz".
You might need a slightly different range on the fader..... 0.1 to 25 or something.
Looking at your video....... seeing (yes, ok, hearing) that you need audible sound.... not 192KHz audiophile sound.... and bearing in mind the original 40Hz analogue signal is inaudible to a lot of people, I don't think the clock problem is going to have a significant effect.

But if you are mistaken about the 40Hz maximum and there is actually more information that you need....... think heartbeat (low) + blood rushing (high) then upping your sample rate from the arduino will be necessary to get the higher frequencies.
500Hz sample rate will only give you up to 250Hz of audio information, just like 44100Hz only renders 22050Hz for our delectation.
David.

P.S. I don't much like maths..... not true..... it is fascinating but too hard for my feeble brain.
But without bothering to work it out, in theory, to preserve the signal the [lop] should be just below half the nyquist... so for 500Hz sampling a [lop~ 240] ?? should do that.
So I was way off base with the [lop~] values I posted above.
The signal would be very reduced (much lower I think) with the values I gave above.
However, [lop~] is not a very "sharp" filter... low dB/octave...... so maybe I was not in fact wrong...... and anyway you will need some distortion so as to properly hear your 40Hz note.
I hope you like to have someone struggling alongside you while you work.
I have to research what that means when the signal has already been oversampled by [sig~]..... but I think it doesn't matter.
Someone clever will tell us first no doubt.

@jameslo 's solution above should give a better outcome though than with a rather uncertain value for [lop~].
It will depend on what you need from your patch.

As far as I know, [sig~] only changes at block boundaries, so it's not really useful for converting fast changing numbers to a signal. You could use [vline~] instead, but I think @jameslo's array solution is probably more suitable anyway. Here's how it can be used in "real time", that is with a min. delay of 2/"SR" for 4-point interpolation (in your case 4 ms). upsampling.pd

@manuels Without ay real timestamp for the incoming data there will be no real value for [vline~] to point to..... and the incoming data, being at control rate, will arrive at the block boundaries into [sig~] anyway.... which is why it only updates at that moment.
At a 500Hz OSC samplerate a message is arriving every 88.2 block samples in Pd on average, but it is possible that 2 messages arrive within a block and so the first is lost.
So without a timestamp no resolution can be accurate which is why I suggested [lop~] as a solution to get an approximate waveform which could be sufficient for the application.... with a phase shift but minimal overhead and no buffer delay.
I cannot see how even tweeking priorities on the wi-fi router could help in this situation.
But I agree otherwise.
David.

Hey @whale-av @jameslo @manuels just dropping a note that all your suggestions are very interesting and I'm gonna work today on implementing and comparing them (got some mileage yesterday refining the patch with sig~ and lop~ with some decent results, next will try the tabread~ options).
I would like to do then a round up and post some results here, then see where to go from there.

and David, yes, I love and am grateful to see other people thinking with me in real time, that's the beauty of these kind of things

Thanks!
M

@MarcoDonnarumma Good luck.....!
Further to my post above... re block boundaries...... 500Hz is close to the maximum sample rate you can send.
At a block size of 64..... 44100/64 = 689.0625 will be the maximum possible sample rate from the Arduino that Pd can process with control rate data (without a timestamp).

With a timestamp to properly separate the values........ stopping previous messages being overwritten when a new message arrives before the block boundary..... [vline~] could set the future sample values from the separated messages (it can queue them...... schedule any number of future ramps) at 44100 single sample accuracy........

Then you could send from the Arduino at a higher sample rate..... with the limit being set by the osc receive socket... which might if you are lucky be higher than the sample rate you are sending.
You might then need to set priorities in your router to get more reliability for the UDP messages (fewer packets lost).

The accuracy that you gain with the timestamp will allow @jameslo 's patch to work properly with the addition of [vline~] as @manuels says.
I will have a look at @manuels's patch later...... you will beat me to it.

That you had some result with [lop~] shows that we are on the right path...
David.

P.S. Router throughput seems high enough. Here is info on router tweeking if you need to...... https://support.tetcos.com/support/solutions/articles/14000121108-what-are-the-settings-to-get-max-throughput-udp-tcp-for-802-11n-and-802-11ac-

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.