[prev in list] [next in list] [prev in thread] [next in thread] 

List:       arts
Subject:    Re: Multithreaded audioiooss for arts
From:       Matthias Welwarsky <matze () stud ! fbi ! fh-darmstadt ! de>
Date:       2001-05-30 8:15:10
[Download RAW message or body]

On Wednesday 30 May 2001 01:11, you wrote:
> I was able to get it to run. I don't see any significant performance
> improvement though. My crude benchmark was to run 5 copies of noatun
> playing ogg sound files. With the standard OSS driver running with
> real-time priority the load average is just less than one. With the
> real-time version it seems to be about 4. This is on a PIII 600 running
> the 2.4.5 kernel and glibc 2.1.

I have run it on about the same machine class (PIII 600), with kernel 2.4.3 
though. I guess the results are also dependent on the settings of the 
fragment size and count of the soundcard.

>
> It also only worked for me if I used the real-time wrapper. Just running
> artsd -a toss did not produce any output and the sound player was
> blocked.

You have to. creating realtime threads needs root privileges, which you don't 
have unless you use artswrapper. As I said, it's more of a proof of concept 
then a "run-under-any-condition".

> Could it be the performance boost is more significant for slower machines
> or when playing videos? Maybe we can get some more benchmark data points.

It's not the performance boost that's interesting here. It's the ability to 
keep the soundcard well fed with data while the machine is under high load. 
However, a load of 4 is not quite what I'd expect. How is the cpu utilization 
of artsd then, as shown by "top"?

My main concerns with arts I have outlined in my previous mail. load figures 
and benchmarks are not that important at the time. I say the design is not 
realtime capable at present, and to make it do realtime, you'd probably have 
to implement a realtime task scheduler based on a mainloop and select() - and 
still it could only do cooperative multitasking. So I say the current design 
is wrong. I'd like to convince you to redesign it using multithreading and 
offer my help.

best regards
	Matthias

[prev in list] [next in list] [prev in thread] [next in thread]