Date: Sat, 06 Apr 2002 05:39:07 From: "neil barnes" <[EMAIL PROTECTED]> Subject: Re: AW: [LIB] recording audio? (danger technical)
>Date: Fri, 05 Apr 2002 18:44:26 +0000 >From: "Matthew Hanson" <[EMAIL PROTECTED]> >Subject: Re: AW: [LIB] recording audio? (danger technical) > >it's very hard to find the exact spot where the clicking appears in the >audio wave shape. It's always easy to edit out clicks that appear as >obvious spikes in the wave shape with one of the various audio editing >tools. But there are no obvious spikes that I can find in these files. Of >course it's easier for me on my Atlhon 800 system out in CA with SoundForge >installed. I'm not very used to using CoolEdit Pro on a Lib. > >But these are definately recorded artifacts. I can select the portion of >the >recorded signal where a click can be heard, and replaying the slection >results in the same click being heard at the same point all the time, so >I'd >think that this would mean that it's not a replay artifact. They are >random >clicks, and don't appear at regular intervals as far as I can tell. They >vary from 2-15 seconds apart. This sounds then as if individual or small numbers of samples are being dropped. Remind me again how you're getting the audio into the machine? > >I actually got a bit better recorded signal using my Toshiba 6.4GB HDD, but >there was still a significant number of clicks. The specs for the Hitachi >20GB HDD show a significatly slower internal transfer rate than the >Toshiba: > >Hitachi DK23BA-20 20GB HDD >Interface Transfer Rate: >Max. 66.6 MB/s (Ultra DMA 4) >Max. 16.6 MB/s (PIO Mode 4, DMA 2) > >Toshiba MK6411MAT 6.4GB HDD >Data Transfer Rate: Internal 86.4 - 153.3Mb/s > Are you comparing apples with oranges here? The only spec you care about is the PIO mode 4, cos AFAIK that's the one that the 50 uses. Of course, it shouldn't make any difference *how* fast the disk is provided it can take 10MB/minute or so, which is well within any of these specs - if it's not ready when the program wants to write then the data should be buffered until such time as it is. Normal (i.e. dos level) audio recording works like this: (please note - I'm working from memory far too early in the morning :) 1) set up two buffers in sequential memory, big enough for a sensible amount of data, say a tenth to a quarter second. Maximum is 64kB cos that's all the DMA can handle. 2) set the sound chip inputs and levels, sample size and speed etc 3) set the sound chip to read enough data to fill your memory blocks in auto dma mode and start it running. From this point it needs *no* processor control until 4) the sound chip reads the last byte in the first buffer and issues an interrupt. It continues to read into the second buffer automatically. 5) you respond to the interrupt by telling the chip to start using the second buffer, and copy the first memory block to the disc. 6) when the second memory buffer is full, it issues another interrupt and starts to record into the first buffer again. 7) repeat 4,5, and 6 until bored. Now the critical point is obviously 5 - if the processor does not get round to recording the data in time, it's going to get stomped on the next time round. Bear in mind that these data levels can be supported by a 386 at around 20MHz clock rates - providing it's not doing anything else at the time. But: a multitasking OS has to virtualise the hardware of the machine on which it is running. It cannot allow programs to talk to the hardware directly - a program doesn't even know the absolute address of the memory it's running in. For example, Windows puts all user programs at or above the 2G boundary, even if it's running in 8 meg. For historical reasons, the DMA hardware has to work with buffers below 16M in physical location. How can my program at 2G speak to memory at 16M? Well, it can't. Not directly. The intel processor can operate at various permission levels - some instructions are available only at ring zero - the operating system level. User programs - living in ring three - cannot use those instructions, but they're the ones it needs to talk to the hardware. Damn. So, we get these horrors that Micro~1 call 'vxd's - virtual device drivers. A vxd is a ring 0 program with an interface which can interface with the user software. It's responsible for making sure that e.g. only one user is trying to use a particular bit of hardware at a time. Disc drivers are vxds, screen drivers are vxds (which is why so many bsod's are video driver related), and the sound drivers are vxds. Now we have a slightly more complex setup. Our sound recording program has to ask a vxd for all the facilities it needs. The vxd checks with the OS that the resource is available, and then locks it out for other users. When the program trys to speak to the sound system, it speaks to the vxd, the vxd switches the processor to ring 0, does the work, and switches back to ring 3 before returning to the user program. When the chip issues the interrupt, it's intercepted by the interrupts vxd, which decides which of the other vxds has hooked it, passes it to that vxd, which performs the context switch again before the user program finds out about it... it also moves the data from where the sound chip put it to where the user can see it, so that the user can tell the OS to move it again to the disk. The net result is that there's an awful lot of swapping things around before anything useful happens... what was a routine taking arounf a dozen instructions or so has turned into thousands and tens of thousands of instructions. At the same time, windows is doing it's time-sharing dance between everything else running, and trying to buffer stuff until it's got sensible amounts of data to move around. In the case of trying to replay audio the data can be buffered several times: o disk to internal disk buffer o internal disk buffer to disk dma buffer o disk dma buffer to user space o user space to direct audio mixer buffer o mixer buffer to audio dma buffer o and finally, replay. Any wonder it has glitches? Neil _________________________________________________________________ Join the world�s largest e-mail service with MSN Hotmail. http://www.hotmail.com ************************************************************** http://libretto.basiclink.com - Libretto mailing list http://www.silverace.com/libretto/ - Archives -------TO UNSUBSCRIBE------- Reply to any of the list messages. The reply mail should be addressed to: [EMAIL PROTECTED] - Then replace any text on the message's subject line: cmd:unsubscribe --------TO UNSUBSCRIBE DIGEST------ Do above but with this on subject line: cmd:unsubscribe digest **************************************************************
