Date: Thu, 11 Jan 2001 21:44:49 -0600 From: Dan Nelson <dnelson@emsphone.com> To: Steve Price <sprice@hiwaay.net> Cc: hackers@FreeBSD.ORG Subject: Re: synchronous IO Message-ID: <20010111214449.A26983@dan.emsphone.com> In-Reply-To: <20010111202855.Y36120@bonsai.knology.net>; from "Steve Price" on Thu Jan 11 20:28:56 GMT 2001 References: <20010111202855.Y36120@bonsai.knology.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In the last episode (Jan 11), Steve Price said: > What are the secrets to doing synchronous IO with FreeBSD? I have > this application that I'm writing where I need to play a WAV file but > I need to make sure all the bits are sent on there way before I move > on. The WAV file is being played through a controller that I have to > toggle some bits via a serial port to get the WAV file through. > Without doing a sleep(3) and praying that IO is complete is there > another way? I'm pretty sure what I need is the equivalent of O_SYNC > in SVR4, but I think I'm drain-bamaged (sic) because I haven't found > the equivalent in BSD. I don't think you really mean synchronous IO; All you need is some buffering. If the toggling you're talking about is direct wave generation (i.e. you have to do something for each byte in the sample), your time restrictions are probably tight enough that you'll want multiple buffers, filled by one process and drained by another one. You mmap() some shared buffer space, fork your process into two, and send buffer status messages over a pipe connecting the two. Process 1: read a block of data from input file, fill an empty buffer, send the buffer address over the pipe, repeat. Process 2: read a full buffer, toggle buffer through the serial port, send the address of the buffer back over the pipe for reuse. This ensures that the only operations P2 does apart from waveform generation are a select, two reads, and a write every sizeof(buffer). You could even toss the pipe and use another bit of shared memory to keep track of buffer usage. If, on the other hand, the toggling merely tells the controller to play a sample that you have already stored in the device's memory, then you presumably have looser timing requirements and can get away with having one process drain and fill the buffers as appropriate. This is similar to how the kernel's soundcard drivers work; most soundcards read system memory directly and signal the kernel via interrupts when its buffers are getting empty. -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010111214449.A26983>