audio: add timestamp to raw files

[harshilbhatt2001]

Fix #9

Creates a new file with a .D extension containing the following data per audio sample.

typedef struct __attribute__((__packed__)) {
	uint32_t seconds;
	uint16_t milliseconds;
	uint16_t buffer_size;
	uint8_t is_mono;
	uint8_t padding;
} audio_metadata_t;

[Era-Dorta]

Great start!

[Era-Dorta]

Neat!

[Era-Dorta]

Sorry, a few more questions. This is a very sensitive change, so I want to make sure that we get it right.

[Era-Dorta]

@Josfemova , can you please also review this PR?

[Josfemova]

sample rate can be a compile-time constant, and the result from the operation PDM_BUF_SIZE / base_sample_rate) * 1000 could be too due to const evaluation if this calc was in a macro instead.

Not functionally different but I would expect that to yield better performance by a slight margin.
Perhaps the calculation of these can be combined with this calculation: https://docs.nordicsemi.com/bundle/ps_nrf5340/page/pdm.html
you could move the value for pdfm_cfg.clock_freq in drv_audio_pdm.c to a define.

You could also take advantage that this now supports C23 and constexpr can be used

[Josfemova]

not sure why the false case is needed here. If this is a second entry the current_time would be by definition at least 2 buffers duration's in value wouldn't it? Could you elaborate, perhaps I'm missing something

[Josfemova]

• @Era-Dorta This got me thinking, wouldn't it be nice to have an endpoint to tell a midge what the current time is? to have a reference to compare the timestamps against?
  IDK if you would consider that useful but came to mind while reviewing this

[harshilbhatt2001]

Could you elaborate

It's for potential timer wrap-arounds. If the timer was about 0xFFFFFFF0and it wraps around to 0x0 then the initial condition will be false and you'd get nonsense values. It shouldn't really happen though because the midge won't be running that long.

[Josfemova]

That was the main reason I initially thought but in practical terms, a Midge will never be ON for enough time for a 64bit msec value to overflow. I think we can safely assume the wrap-around case will never be executed

[Josfemova]

lgtm

[Era-Dorta]

lgtm too, I had one comment that I forgot to click send on but feel free to merge as is.

[Era-Dorta]

Answered in the comment, all good to merge.