Add a delay to mic recording.

[cjb]

Ben Schwartz reports that, at the moment, approximately the first 4000 samples (~100ms) of every microphone recording are contaminated with a full-range pop, as a consequence of recording while the offset is still stabilizing after the mic bias is applied.

Ben says that the nastiest (negative) part of the pop is over after about 30 samples, but it takes the rest of the 4000 for the DC bias to equilibrate.

Mitch and Ben suggest trying a 50ms delay inbetween bias on and recording, seeing if there's an audible click present in the recording, and halving the delay and trying again if not. I suggest doing this in snd_cs5535audio_capture_open(), which is the kernel function that applies the mic bias.

[bemasc]

A plot of the first 100 samples of a mic recording on a B4 at 48 KHz.

[bemasc]

A plot of the first 100 samples of a mic recording on a B4 at 48 KHz.

[bemasc]

A plot of the first 10000 samples of a mic recording on a B4 at 48 KHz.

[bemasc]

I am using the microphone for purposes other than recording human-listenable sound, so whether or not there is an audible click is not directly relevant to me. I will have to test to see whether any delay is sufficient. However, I expect that any delay of at least 1 ms will be a great improvement. A delay of 50 ms would definitely be enough.

[ethrop]

This problem goes way back. At least 6 months ago, we had to write in a delay for recording with the mic in miniTamTam to "jump" over the initial 200 samples or so. As far as I know we haven't taken that code out so I would advise ample warnings if another delay is added. Olivier on CC.

[AlbertCahalan]

Replying to ethrop:

This problem goes way back. At least 6 months ago, we had to write in a delay for recording with the mic in miniTamTam to "jump" over the initial 200 samples or so. As far as I know we haven't taken that code out so I would advise ample warnings if another delay is added. Olivier on CC.

This is probably the right solution anyway. (each program delays for itself) Not every program will have the same needs regarding delay.

[cjb]

This is probably the right solution anyway. (each program delays for itself) Not every program will have the same needs regarding delay.

What kind of program would have the "pop all over my sample for 100ms" need? I think this belongs in the driver.

[dilinger]

Replying to cjb:

This is probably the right solution anyway. (each program delays for itself) Not every program will have the same needs regarding delay.

What kind of program would have the "pop all over my sample for 100ms" need? I think this belongs in the driver.

Synth Pop recording, of course!

I agree that this belongs in the driver.

[AlbertCahalan]

Replying to cjb:

This is probably the right solution anyway. (each program delays for itself) Not every program will have the same needs regarding delay.

What kind of program would have the "pop all over my sample for 100ms" need? I think this belongs in the driver.

There was no one single point in time that made the signal go from perfectly useless to perfectly useful.

At 24 samples (0.5 ms) it was looking pretty good. Others will disagree. Even at 17 samples it was kind of decent, with just a bit of ringing.

Plus there is the matter of latency from a kernel-enforced delay, assuming you don't supply zeroes during that delay. Delaying for many milliseconds would be terrible.