No direct /dev/dsp mixing?

[jamie]

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.

cheers,
jamie

[dev]

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.

cheers,
jamie

Hi,


Mixing works but you need to tell each app to use a specific /dev/dsp (type cat /dev/sndstat and find which devices are the VMIX device).

THe automatic opening of devices in FreeBSD doesn't work because it doesn't follow standard Linux or Solaris or SYSV semantics.

Looks like we aren't the only ones asking for this.
http://lists.freebsd.org/pipermail/free ... 16995.html


EVENT_HANDLER() calls don't handle the direction of open whether it's read or write so in the case of OSS when we open /dev/dsp for write, we need to pass the the O_WRONLY flag to open so that it can find which device is a playback device.


The Other problem with EVENT_HANDLER is that it seems to only do it for devices that don't have a /dev node - in OSS we already have the device node in /dev/when the VMIX driver is installed.

So if any FreeBSD kernel hacker is looking here, please contact me.

regards
Dev

[jamie]

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.

Cheers,
Jamie

[dev]

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.

Cheers,
Jamie

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.


regards
Dev Mazumdar

[trew]

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.


regards
Dev Mazumdar

Well, the native driver for soon to be released FreeBSD 7 already support vchan for record, transparently handled by just "/dev/dsp".

[hannu]

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]

[trew]

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]

Thanks for the explanation.

FYI, I've tested FreeBSD 7.x (soon to be released) default driver and try to reproduce any misbehaviour without any success (opening "/dev/dsp" with O_RDONLY, WRONLY, RDWR, multiple forks/threads, doing stat() and lstat() repetatively). If I really want to open any specific playback or record device, I can simply point to "dsp0.p0", or ".vp2" (virtual playback) or ".vr10" (virtual record).

Looks like they did it right