Hi, On 01.06.2011 01:02, pete.goodeve@xxxxxxxxxxxx wrote:
On Tue, May 31, 2011 at 01:33:27PM -0700, scottmc wrote:It's been awhile since I used OpenSound, anyone tried it since the recent IO-APIC fixes? I wonder if the long startup delay is still there?
I've been trying to see if I can get OpenSound working on the laptop under a current build. Last night I did get sound out, using the files that were originally there (dating from 2009, I think). The usual wait after boot before it would work was still there. I've replaced them today with the current optional package, and so far have complete silence! Maybe I haven't waited long enough yet...
Waited for what? Someone to suddenly have the motivation and skill to improve the OSS port? Maybe it needs to be you...
I'm beginning to think OSS is a bit of a waste of time. The audio buffer size is 16384, which gives a latency of 1/3 sec! There seems to be no easy way to change this, and it makes it useless for me. (This latency is also probably the reason for the silence. Don't really understand why, but I had the same problem on my machine using auich until I found that a settings file that reduces the buffer size to 256 should be installed. [ticket #7284])
I have no idea how you came to the conclusion that there is no easy way to change the large buffer size. Even if I hadn't previously been working on the OSS media node myself, I would probably have guessed that something like a buffer size is pretty easy to change. You just need to find the spot.
Look, Pete, this is Open Source. It just works like it works.Francois did a great job doing the initial port of OSS. The work is split in two parts. The port of OSS itself, and this part works just fine, as can be seen by running the OSS test apps (ossplay and such).
The second part is the media node that interfaces with OSS. That is no port, but a native media server add-on. It was based on the code for the multi-audio node, but an older version of it.
At some point in time, I wanted to play back music on one of my computers and only the OSS port provided a driver for the sound card I had. At the time, the test apps would produce audio without glitches, but the node would not. So I dug into the code of the node, which is included in the Haiku source, BTW, not part of the OSS package, and changed a lot of things, diverting it farther away from the multi-audio code. At the time, Haiku had horrible scheduling latency, so I put in code which calculates the buffer size large enough to not get glitches when playing back music. On your machine, it ends up being 16384 bytes per buffer. Of course, for your purposes, this is unusable. For me it got the node into "working good enough" condition for my purpose of playing back music - at that time.
A while after this, much work went into improving the native HDA driver. And not only the driver was improved, but the thread scheduling and latency as well. The multi-audio node uses now a much smaller buffer size and can play back without glitches and low latency.
Right now all my hardware has audio support with native drivers, so I never had the motivation to change anything in the OSS node, since I am not using it. It was never adjusted for the improved kernel latency.
If you have a need for OSS to better suit your needs, dive into the code of the node, find the spot where it calculates the buffer size and experiment. Be glad that other people put in enough work so that you can probably get away with changing about three lines of code to fix your problem and stop complaining that nobody else had any interest in looking at it, yet.
src/add-ons/media/media-add-ons/opensound/OpenSoundDeviceEngine.cppLook at Open() and AcceptedFormat() and the place in OpenSoundNode.cpp which uses these methods.
And sorry if I misread the tone of your mail. ;-) Best regards, -Stephan