Thanks for replying. On Thu, Jan 21, 2010 at 10:51 AM, Hannu Savolainen <ha...@opensound.com> wrote: > The way to do this is to use a select loop. Every time the device > reports that some data is available then read one fragment of it (do not > check how much data there is available).
Does this mean that the reason I was getting the uiomove error was because I was trying to determine the amount of data in the buffer? I used a select method like I mentioned but I got an identical error. > This read may block a fraction > of second but it doesn't matter provided that the fragment size is > reasonably small. That plus the fact that there's a little bit of processing time in every write is the problem that haunts all applications like this, I write several buffers of silence to the device to combat this. Thanks for the answer. I decided to rethink my entire approach to the application anyway, so instead of using one program to write several input channels to several output channels, I instead am doing it so that the program writes from one input channels to as many output channels as necessary. I'd run these side by side with increased priority, using another daemon to manage the audio flow, and let the kernel take care of the scheduling. This way I don't have to mess around with blocking or selecting, I can just let the read block for as long as it needs to. Hopefully simpler will work better. Another question: if I am using two different nodes which both refer to the same device for input and output, for example: reading from /dev/oss/oss_envy240/pcmin0 writing to /dev/oss/oss_envy240/pcm1 Do I need to set the device into duplex mode with SNDCTL_DSP_SETDUPLEX because they are on the same physical card? > Use of non-blocking I/O is asking for troubles. It is a flow control > method directly from hell. > > Best regards, > > Hannu > ---- > Sherwin Soltani wrote: >> Hello, >> >> I'm using OSS 4.2 on CentOS 5.4, developing a special purpose >> application. In our system we have two PCI audio cards using the >> envy24 driver. In total there are 4 stereo inputs and 4 stereo >> outputs. We want to use this application to control the flow of audio >> data dynamically, by accepting commands over a sockets interface and >> interpreting them to let us switch different inputs to play over >> different outputs. >> >> I figured this should be pretty easy by simply opening the device >> nodes corresponding to each of the different input channels and output >> channels, then by reading and writing data in a loop. I soon realized >> this approach was a bad idea, because the semantics of read in OSS by >> default block until all data is available. >> >> Long story short I tried two approaches based on the duplex example in >> the developer's documentation. The first was to use select to wait >> until there was data available, then use ioctl to find out how much >> data was in the input buffers, then do a read on that amount of data >> and redistribute it to the output devices. The second approach was to >> set the devices into non-blocking mode, which I know is not >> recommended, but I make sure the loop doesn't run over the >> interrupts/sec limit. >> >> In both situations I get this error which seems to stop all progress >> on my console: >> >> copy_to_user(131072) failed(1) >> osscore: audio: uiomove(UIO_READ) failed >> >> In my application, I notice the first read from the devices always >> succeeds like I would expect, but every subsequent read after that >> fails with the error "Bad address". The driver error messages and the >> errno correlate, so I'm guessing the second is caused by the first. >> >> Why is this happening? Is there something odd about full duplexing on >> devices that I need to know, besides the obvious problem which is >> timing? I think I can solve the timing thing by doing what the docs >> suggest, which is writing a few seconds of silence to a device to >> allow input data to buffer up. The latency I don't so much care about, >> although less is better. >> >> Any help is greatly appreciated. I hope this is the right mailing list >> for this question. >> > > _______________________________________________ > oss-devel mailing list > oss-devel@mailman.opensound.com > http://mailman.opensound.com/mailman/listinfo/oss-devel > -- Sherwin A. Soltani, NREMT-B WYBC Student Engineer _______________________________________________ oss-devel mailing list oss-devel@mailman.opensound.com http://mailman.opensound.com/mailman/listinfo/oss-devel
