Sorry, to bombard you like this, I just took a look at the select problem. With Libaudioio it would be better to poll using the libaudioio polling primative and simply yield if not ready, then you wont see a notification come back positive unless libaudioio has reached its low water mark as specified. Problem is exagerated as the latency management in libaudioio prevents the streams queue from ever getting full and therefore you casn always write as far as the os is concerned.
On Tue, 20 Nov 2001 08:20, you wrote: > Hi! > > On Sat, Nov 17, 2001 at 08:23:46AM +1000, Robert Lunnon wrote: > > On Solaris, Why is arts so processor intensive just playing wave files. > > I profiled libaudioio and it uses miniscule cpu ( <5%) but the arts > > daemon ends up using 85% or more.... Any Ideas > > I'd say its because the libaudioio support in aRts is using select() on the > file descriptor, which causes the following cycle: > > 1. artsd writes some audio data > 2. artsd calls select() on the audio file descriptor > 3. solaris realizes after a few samples that the audio buffer is not > entierly full > 4. select() returns -> start with 1. again > > I am not sure if there is a way on solaris to tell the operating system: > only wake up on select() if there are at least ... samples free in the > output buffer. On Linux/OSS this is usually done implicitely by the > fragment size (select() wakeup with 1 free fragment or more), or on > Linux/ALSA explicitely by setting a boundary. > > If that can't be achieved, you could use a timer driven approach rather > than the select driven approach. The other solaris driver, which doesn't > use libaudioio, does this. So this one doesn't cause 85% cpu usage on > solaris. > > Btw, talking about libaudioio, have you seen CSL? ;) > > Cu... Stefan
