Opened 7 years ago

Last modified 7 years ago

#3813 new defect

Add a delay to mic recording.

Reported by: cjb Owned by: dilinger
Priority: high Milestone: 8.2.0 (was Update.2)
Component: kernel Version:
Keywords: Cc: jayakumar, olivier.belanger@…, bemasc
Blocked By: Blocking:
Deployments affected: Action Needed:
Verified: no

Description

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.

Attachments (3)

first100.pdf (3.3 KB) - added by bemasc 7 years ago.
A plot of the first 100 samples of a mic recording on a B4 at 48 KHz.
first100.2.pdf (3.3 KB) - added by bemasc 7 years ago.
A plot of the first 100 samples of a mic recording on a B4 at 48 KHz.
first10000.pdf (29.9 KB) - added by bemasc 7 years ago.
A plot of the first 10000 samples of a mic recording on a B4 at 48 KHz.

Download all attachments as: .zip

Change History (12)

Changed 7 years ago by bemasc

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

Changed 7 years ago by bemasc

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

Changed 7 years ago by bemasc

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

comment:1 Changed 7 years ago by 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.

comment:2 Changed 7 years ago by jg

  • Cc jayakumar added
  • Milestone changed from Untriaged to First Deployment, V1.0
  • Owner changed from cjb to dilinger

comment:3 follow-up: Changed 7 years ago by ethrop

  • Cc olipet added

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.

comment:4 Changed 7 years ago by ethrop

  • Cc olivier.belanger@… added; olipet removed

comment:5 in reply to: ↑ 3 Changed 7 years ago by 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.

comment:6 follow-ups: Changed 7 years ago by 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.

comment:7 in reply to: ↑ 6 Changed 7 years ago by 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.

comment:8 in reply to: ↑ 6 Changed 7 years ago by 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.

comment:9 Changed 7 years ago by bemasc

  • Cc bemasc added
Note: See TracTickets for help on using tickets.