Date: Sun, 31 Aug 1997 05:52:23 +0200 (MET DST) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: hasty@rah.star-gate.com (Amancio Hasty) Cc: dec@phoenix.its.rpi.edu, hackers@FreeBSD.ORG, multimedia@FreeBSD.ORG Subject: Re: IRQ problem (was Re: IRQ timing) Message-ID: <199708310352.FAA03652@labinfo.iet.unipi.it> In-Reply-To: <199708310258.TAA00923@rah.star-gate.com> from "Amancio Hasty" at Aug 30, 97 07:58:21 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> We need a little bit more of information: > o OS version > o is the card using auto dma? > o dma channels being used for the sound card > o name of the app > o buffer size used in in the application i guess you also need the blocksize -- the size of each DMA transfers -- and not only the total amount of buffers. > o complete dmesg output -- i want to know cpu model, etc.. > o sound card brand/model > > > > I just sent a message to the OSS people, and they mentioned that some of > > > > the problem I am experiencing is a result of some tight IRQ timing that > > > > the FreeBSD kernel has (ie, it takes too long to transfer the data). I > > The exact problem is that at the highest sampling rate > > (44.1KHz/16Bit/Stereo) I get skips in the music, even in an unloaded > > system. I emailed 4front-tech about this and said that it was a known > > problem due to FreeBSD's tightness in the IRQ code. I was hoping that The relevant files are vector.s and icu.s in /sys/i386/isa The code for a regular interrupt handler registers the interrupt, re-enables the controller, and dispatches the interrupt if not blocked by some splXX() calli (otherwise the handler will be invoked as the software priority mask will allow it. I don't see where the problem could be in FreeBSD, unless there are long sections of code running with int masked (which should not happen in general, and almost certainly doesn't if the system is unloaded.) The OSS code probably uses use AUTO dma mode, so if the application can feed (or drain) data fast enough from the buffers, interrupt latency does not count provided you have a decent blocksize. At the highest audio speeds you have about 176KB/s so even using 2KB blocks (which are short for that speed) you have about 10ms to respond to the interrupt. I would rather look at the following: - what blocksize is used by your application ? - is the system really unloaded ? you might be reading/writing data from/to disk, and the latter might just be unable to support the required transfer rate (quite easy if it is nfs-mounted). Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708310352.FAA03652>