Date: Wed, 20 Oct 2004 20:28:55 +0100 From: barnacle <[EMAIL PROTECTED]> Subject: Re: [LIB] Win98/70CT audio playback: A lost cause?
On Wednesday 20 October 2004 07:59, you wrote: > Date: Tue, 19 Oct 2004 23:58:58 -0700 (PDT) > From: Matt Hanson <[EMAIL PROTECTED]> > Subject: Re: [LIB] Win98/70CT audio playback: A lost cause? ... > Then, I guess this really isn't the place to be asking > about this. There's never been very much conversation > about audio issues on the list. I keep telling myself > I ought to Google around the net a bit and see what > other support groups I might be able to find. Not quite a lost cause, Matt... <puts audio engineer's hat on> A collection of things that can cause audio glitches... 1) physical breakdown of components in the audio amplifier - capacitors, semiconductors being the most likely. 2) non-monoticity in the d-a converters 3) breaks in the data stream to the d-c converters, caused by: - the cpu does not allocate sufficient time to update buffers - the cpu cannot decode the data in the time available - the disc drive cannot deliver the data in time - the disc takes time out to recalibrate its hardware, and has insufficient space on its buffer ram to cover the glitch 4) Problems with the decoder software, including: - errors decoding the bitstream - errors allocating memory - problems with non-standard bit-streams - problems interfacing with the hardware ram buffers Of these, (1) will show itself randomly, though it may be dependent on time of operation (and therefore heat), and it will occur whether audio is being replayed or not. (2) will show every time the signal ramps past the non-monotonic part of the signal. Expect symptoms ranging from apparently simple noise to aliasing or even frequency doubling. (3) will show as short silences in the audio, randomly, so not appearing at the same point every time you replay the same track. (4) might be randomly timed dropouts, or might occur at the same point in the bitstream. As the problem increases with time - and presumably heat - I'd be inclined to suspect something from (3), if it's showing as noticeable pauses. If it's just ticks, then it's likely caused by sudden jumps in the dac output, perhaps because samples have been missed or because there's a driver problem. For what it's worth, I had problems on the 70 with ticking on a .ogg decoder; it would gradually start to tick on both channels, and appeared to be dropping the occasional sample. If you paused and restarted the decode, the audio image would shift back to the centre, an implication that data was not being replayed at the same speed in both channels (!). The audio hardware in a PC is bizarre, mostly for legacy reasons. The audio chip can only access buffers in the lower 16MB, and there are restrictions about crossing 64kB boundaries <sigh>. This is controllable in DOS, but once you add W95/8 and directSound to the mix it gets really silly: data is decoded to an upper memory buffer (all user program memory is allocated in the top 2GB of the memory space, mapped to wherever the physical memory is), mixed (and possibly rate changed) with any other audio present to a second buffer, and transferred to the final buffer; then, it's DMA'd by the audio output chip. The data rate coming off the disc is miniscule in processor terms... even a 384kb/s rate only equates to 48kB/s, nothing, really. This probably hasn't helped you... but my guess is still software. I found when I was running the 70, which I had overclocked IIRC, that most of the audio programs couldn't hack it. Certainly I didn't want *anything* that had on-screen animation going on. Sonique is one that I use a lot, uses very little processor time, though you might be able to find an older version. Another one I used successfully was mpg123 for dos; there are a few versions hanging around but http://www.fareham.org/mpg123/ is probably a good start. It's command line only, and you can set all sorts of things like forcing mono playback (less decoding) and setting bigger buffers. IIRC it runs in a dos box. Worth a play. Hope this helps, Neil
