jamie wrote:I just installed the v4.0 OSS and am impressed by it's facilities...
However, there is one major reason why I'm switching back to the default free/oss that is part of FreeBSD:
From what it seems, I still need to specify a different dsp device for each sound source.
In the default FreeBSD version, everything just uses /dev/dsp, and if there is more than one application opening it, so be it -- they mix automatically.
I can fire up many different sound-sources without getting the 'device busy' problem.
It seems that as many sources as I like can open /dev/dsp and they'll be mixed automatically.
Can't OSS 4.0 do this ?
FWIW, I'm using a sound blaster live card.
jamie wrote:Dev, thanks for the quick response.
So, if I understand this correctly, the way FreeBSD does it with it's own OSS implementation is "non-standard", and when (and if) FreeBSD provides a 'standard' way of doing this, both you (and Nvidia graphics, relating to your link) will be able to use this to achieve these goals ?
If so, I'm happy to wait for this to happen, though in 'real-life terms' it is still a shame, because cut-to-the-chase, I have an 'oss' driver now that already does this, whilst your more-featured driver does not.
I know I can specify different /dev/dsp* devices for different applications, but this is really a hassle - especially when I don't need to do this with the 'native' driver.
On a more positive note, I do LOVE OSS, and the support/dedication you've given it -- especially to FreeBSD - there are always uptodate versions for FreeBSD, and I'm very grateful you've not followed the "the only unix is linux" hype that seems to be polluting things these days.
dev wrote:Hi Jamie,
Basically FreeBSD's vchans support is something similar to what we would like to achieve but vchans will basically not work in our implementation because vchans assumes that the device that is being cloned is a playback ONLY device and so it doesn't care about the OPEN flags - in OSS we can virtualize input as well - ie multiple recording apps can be run at the same time so we need to tell the clone handler that the device we need is an input device.
Thanks for your kinds words - hopefully we can get the OSS drivers under a BSD license soon.
hannu wrote:We tried to use the clone() service but it was not suitable for OSS for several reasons:
- The clone entry point doesn't give the open mode (O_RDONLY, O_WRONLY or O_RDWR). OSS uses the access mode to select a device that supports this mode. The stock FreeBSD driver assumes O_RDWR which will not work with many OSS devices that have separate input and output device files.
- OSS doesn't use open redirection just with /dev/dsp but with all devices because the vmix driver can be enabled for several devices. If we use the clone method then /dev entries for most devices will be hidden which is not nice.
- If the devices under /dev/oss are hidden then the ossdevlinks program that manages the legacy (/dev/dsp#, /dev/mixer#, etc) devices will no longer work.
So using the clone approach will cause more problems than it solves.
We proposed an approach where the drvopen() entry point could return
the right device number in a way that doesn't conflict with the current return value semantics (OPEN_REDIRECT|mkdev(major,minor) or -mkdev(major, minor). However this proposal was not accepted.[/list]
Users browsing this forum: Google [Bot] and 1 guest