On Thu, 10 Jan 2002, Christopher C. Chimelis wrote:
> On Thu, 10 Jan 2002, Siggi Langauf wrote:
>
> > After a night of sleep and some more listening, I found out that these
> > sonds occur when there is acces to the hard disk drive.
> > I'm using ext3, therefore the regular peaks.
> > When I do something like "find / -type f|xargs cat >/dev/null", I get a
> > constantly chirping sound (still very high pitch and very low volume...)
> >
> > I guess it's a hardware issue, but haven't tried with MacOS yet.
>
> I don't boot over to OS-X or MacOS 9 very often, so if you get a chance to
> test it before I do, let me know the results.
I usually don't boot that machine at all, but today I got the chance, and
I can verify that it produces the same noise in MacOS X. The patterns are
a bit different, but that's due to the different hd access
characteristics...
> > Maybe one could filter that out...
>
> I'm hoping so :-)
Hmm, that would probably kill some high-frequency part of the audio
spectrum as well, but maybe there's a chance to do better than Apple ;-)
[...]
> In all fairness, headphone speakers seem to be matched with their usage
> better than the internal speakers on my TiBook (which suck, IMHO, but
> they're not THAT bad all things considered)...dunno about the iBook, but I
> would expect roughly the same.
Yup, they suck, even with iTunes' "small speakers" profile, they used to
sound, well, small...
[...]
> > Maybe you want to have a look at the suspend mode: When pmud puts the
> > machine to sleep while playing mp3s, I sometimes get strange noises when
> > it wakes up again. The only way to fix this is to unload/reload the sound
> > modules...
>
> Well, the tumbler is an odd device and probably unlike most sound cards
> that people have experienced. Most likely, it's not really the suspend
> bits in the sound driver (which there aren't any, really), but rather the
> suspend bits in the I2C drivers (since tumbler is an I2C device rather
> than a PCI bus device like most sound chips/cards). I am pretty familiar
> with the I2C code, so maybe I'll look at that as well. I probably should
> be sending the chip a reset on wakeup, but I haven't implemented any real
> reset code yet.
Resetting the chip sounds like the right thing to do, though I don't
actually know what I'm talking about ;-)
Note that I only get such noise effects in one out of 10...20 sleep/wake
cycles, so it's not easy to reproduce...
Happy hacking,
Siggi
