OSS mains HUM filtering 50Hz / 60Hz ?
Hans Petter Selasky
hps at selasky.org
Wed May 14 10:57:41 UTC 2014
On 05/14/14 12:12, Ian Smith wrote:
> On Wed, 14 May 2014 10:07:01 +0200, Hans Petter Selasky wrote:
> > On 05/13/14 20:31, Hans Petter Selasky wrote:
> > > Hi,
> > >
> > > Some of my USB audio headsets seems to be picking up mains HUM even if
> > > powered from battery. At first I thought the mains HUM came from the
> > > computer, but then I did some work and I verified my findings by
> > > sampling the AC network using a non-switching power supply. Maybe it
> Hmm, by non-switching I suppose you mean via a transformer .. the ripple
> quality won't necessarily be better than a switched supply; it's down to
> the final filtering usually.
Right, via a transformer and a simple voltage regulator I think.
> Any HV power lines or an electricity sub-station near you? (induction)
I need to check it out.
> > > does not belong in the FreeBSD audio stack, but I think it would be very
> > > clever to have a configurable band-reject filter in the FreeBSD DSP
> > > framework for 50 and 60Hz? Do we have such a filter mechanism already?
> > >
> > > Not sure if this is a so-called "feature" or not ... :-)
> > >
> > > http://en.wikipedia.org/wiki/Mains_hum
> > >
> > > http://www.selasky.org/hans_petter/hum.png
> Are those units mV, or what?
It is not mV. I simply scaled the output from the transformer 12V using
some KOhm resistors and recorded that using another sound card. I just
wanted to check if the received hum was actually from the power grid or
not, and looking at the phase, indeed it was.
> > I tried the following patch with some success:
> > === pcm/feeder_chain.c
> > ==================================================================
> > --- pcm/feeder_chain.c (revision 265912)
> > +++ pcm/feeder_chain.c (local)
> > @@ -721,7 +721,7 @@
> > /* Soft EQ only applicable for PLAY. */
> I'm wondering why Ariff chose to only apply it for playback?
> > if (cdesc.dummy == 0 &&
> > - c->direction == PCMDIR_PLAY && (d->flags & SD_F_EQ) &&
> > + (d->flags & SD_F_EQ) &&
> > (((d->flags & SD_F_EQ_PC) &&
> > !(c->flags & CHN_F_HAS_VCHAN)) ||
> > (!(d->flags & SD_F_EQ_PC) && !(c->flags &
> > CHN_F_VIRTUAL))))
> cdesc.use_eq = 1;
> Can you give a quick pointer to the actual EQ code (just curious as to
> how it's done, having just taken the pcm code on faith so far).
I tested the patch above and it seems to work. It works for both RX and
> > And setting:
> > hint.pcm.0.eq=1
> > hint.pcm.1.eq=1
> > hint.pcm.2.eq=1
> > hint.pcm.3.eq=1
> If that turns out to be a real solution to this problem, might we then
> need separate en/disabling of PLAY and REC eq?
I think the problem is a bit more complicated. I ended up routing the
audio signal through a real software EQ using JACK, and that seems to do
the trick a bit better.
> Here I'm directly generating 24-bit wave files, some of which are around
> 50Hz (plus harmonics), and some occasionally as low as ~22Hz, so I need
> specifically to not suppress these on playback, though finding amps or
> headphones that don't dampen these freqs too much can be fun ..
Of course, the USB audio equipment I'm talking about in this case is not
professional. All 16-bit cheap headset stuff. Although I was surprised
about the level of hum and I also noticed that this audio device from
Logitech, also is sensitive to 2.4GHz .... When using a wireless mouse
it also picks up noise from that one ... :-) On the other hand I'm not
surprised if this is a so-called "feature" ;-)
More information about the freebsd-multimedia