The OSS API (http://www.opensound.com/pguide/oss.pdf, page 102ff)
specifies that a select _with the sounddriver's filedescriptor
set in the read mask_ should start the recording.
Implementing this is currently not possible, as the driver does
not get to know whether the application had the filedescriptor
set in the select call. Similarily for poll, the driver does not
get the caller's events.
Different drivers do it differently. The ISA SB driver just
unconditionally starts recording on select, whether the bit
in the read mask is set or not. es137* unconditionally does
not start recording. Both drivers violate the API.
I don't think this is all that important though, because
it's that way for more than a year and the first complaint
reached me yesterday.
Comments?
Tom
On Thu, 2 Nov 2000, Thomas Sailer wrote:
> The OSS API (http://www.opensound.com/pguide/oss.pdf, page 102ff)
> specifies that a select _with the sounddriver's filedescriptor
> set in the read mask_ should start the recording.
>
> Implementing this is currently not possible, as the driver does
> not get to know whether the application had the filedescriptor
> set in the select call. Similarily for poll, the driver does not
> get the caller's events.
The specification is bogus and should be fixed. select() is not
a function that was designed to start/stop anything. Writing
a specification to qualify some particular implementation's
side-affects is patently wrong. ioctl() was designed to control
things.
You should contact a committee member and get it fixed. Further,
all should fail to write code to such a so-called specification.
If specifications are allowed to be written like this, soon
the lights will go out when you open a file. This cannot be
allowed. Don't support such diatribe.
Cheers,
Dick Johnson
Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
"Richard B. Johnson" wrote:
> The specification is bogus and should be fixed. select() is not
Don't tell me, I didn't write that spec.
> side-affects is patently wrong. ioctl() was designed to control
> things.
It already exists, ioctl(fd, SNDCTL_DSP_SETTRIGGER, PCM_ENABLE_INPUT).
If we officially declare the poll/select side effect to be
unacceptable, I'm happy with it, as my sound drivers already
work that way 8-)
Tom
"Richard B. Johnson" wrote:
> The specification is bogus and should be fixed. select() is not
> a function that was designed to start/stop anything. Writing
> a specification to qualify some particular implementation's
> side-affects is patently wrong. ioctl() was designed to control
> things.
>
> You should contact a committee member and get it fixed. Further,
> all should fail to write code to such a so-called specification.
>
> If specifications are allowed to be written like this, soon
> the lights will go out when you open a file. This cannot be
> allowed. Don't support such diatribe.
We are stuck with the current OSS API, including warts aplenty, until
ALSA replaces it. (but even then OSS will live on in infamy...)
Jeff
--
Jeff Garzik | Dinner is ready when
Building 1024 | the smoke alarm goes off.
MandrakeSoft | -/usr/games/fortune
On Thu, 2 Nov 2000, Thomas Sailer wrote:
> "Richard B. Johnson" wrote:
>
> > The specification is bogus and should be fixed. select() is not
>
> Don't tell me, I didn't write that spec.
>
> > side-affects is patently wrong. ioctl() was designed to control
> > things.
>
> It already exists, ioctl(fd, SNDCTL_DSP_SETTRIGGER, PCM_ENABLE_INPUT).
> If we officially declare the poll/select side effect to be
> unacceptable, I'm happy with it, as my sound drivers already
> work that way 8-)
>
Of course!
Cheers,
Dick Johnson
Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
Thomas Sailer wrote:
>
> The OSS API (http://www.opensound.com/pguide/oss.pdf, page 102ff)
> specifies that a select _with the sounddriver's filedescriptor
> set in the read mask_ should start the recording.
>
> Implementing this is currently not possible, as the driver does
> not get to know whether the application had the filedescriptor
> set in the select call. Similarily for poll, the driver does not
> get the caller's events.
Well, it's only a problem for full duplex :) If you are write-only in
poll(), read doesn't apply. Read-only in poll(), and you start DMA.
For full duplex... my Via driver starts DMA'ing. That was my
interpretation of the spec.
> I don't think this is all that important though, because
> it's that way for more than a year and the first complaint
> reached me yesterday.
What was the complaint?
FWIW I highly recommend Rui Sousa's oss-test stuff. Check out the
"emu10k1" module from Creative's CVS server, and look in the
emu10k1/utils/oss-test directory.
Regards,
Jeff
Creative CVS info:
export
CVSROOT=:pserver:[email protected]:/usr/local/cvsroot
echo note - password is 'cvsguest'
--
Jeff Garzik | Dinner is ready when
Building 1024 | the smoke alarm goes off.
MandrakeSoft | -/usr/games/fortune
On Thu, 2 Nov 2000, Thomas Sailer wrote:
>
> The OSS API (http://www.opensound.com/pguide/oss.pdf, page 102ff)
> specifies that a select _with the sounddriver's filedescriptor
> set in the read mask_ should start the recording.
So fix the stupid API.
The above is just idiocy.
Linus
> On Thu, 2 Nov 2000, Thomas Sailer wrote:
> >
> > The OSS API (http://www.opensound.com/pguide/oss.pdf, page 102ff)
> > specifies that a select _with the sounddriver's filedescriptor
> > set in the read mask_ should start the recording.
>
> So fix the stupid API.
> The above is just idiocy.
Its a documentation error. The implemented API does not follow it.
Linus Torvalds wrote:
>
> On Thu, 2 Nov 2000, Thomas Sailer wrote:
> >
> > The OSS API (http://www.opensound.com/pguide/oss.pdf, page 102ff)
> > specifies that a select _with the sounddriver's filedescriptor
> > set in the read mask_ should start the recording.
>
> So fix the stupid API.
>
> The above is just idiocy.
We're pretty much stuck with the API, until we look at merging ALSA in
2.5.x. Broken API or not, OSS is a mature API, and there are
spec-correct apps that depend on this behavior.
(FWIW, ALSA nicely marginalizes its OSS support into a single module, so
that ALSA drivers aren't affected by OSS' ugliness)
Jeff
--
Jeff Garzik | Dinner is ready when
Building 1024 | the smoke alarm goes off.
MandrakeSoft | -/usr/games/fortune
On Sat, 4 Nov 2000, Jeff Garzik wrote:
> > So fix the stupid API.
> >
> > The above is just idiocy.
>
> We're pretty much stuck with the API, until we look at merging ALSA in
> 2.5.x. Broken API or not, OSS is a mature API, and there are
> spec-correct apps that depend on this behavior.
Considering that about 100% of the sound drivers do not follow that
particular API damage anyway (they can't, as has been pointed out: the
driver doesn't even receive enough information to be _able_ to follow the
documented API), I doubt that there are all that many programs that depend
on it.
Yes, some drivers apparently _try_ to follow the spec to some degree, but
we should just change the documentation asap.
Linus
Linus Torvalds wrote:
>
> On Sat, 4 Nov 2000, Jeff Garzik wrote:
> > > So fix the stupid API.
> > >
> > > The above is just idiocy.
> >
> > We're pretty much stuck with the API, until we look at merging ALSA in
> > 2.5.x. Broken API or not, OSS is a mature API, and there are
> > spec-correct apps that depend on this behavior.
>
> Considering that about 100% of the sound drivers do not follow that
> particular API damage anyway (they can't, as has been pointed out: the
> driver doesn't even receive enough information to be _able_ to follow the
> documented API), I doubt that there are all that many programs that depend
> on it.
>
> Yes, some drivers apparently _try_ to follow the spec to some degree, but
> we should just change the documentation asap.
Fine with me. Allows for some driver simplification, and it only
applies to the lesser-used recording stuff at any rate.
Jeff
--
Jeff Garzik | Dinner is ready when
Building 1024 | the smoke alarm goes off.
MandrakeSoft | -/usr/games/fortune
Linus Torvalds wrote:
> Considering that about 100% of the sound drivers do not follow that
> particular API damage anyway (they can't, as has been pointed out: the
> driver doesn't even receive enough information to be _able_ to follow the
> documented API), I doubt that there are all that many programs that depend
> on it.
While I'm thinking about the subject.. even after updating the API, the
drivers still need to know what events to poll for.
AFAIK 99% of the drivers currently select to block on
read/write/read+write based on file->f_mode, which works, but isn't
really correct.
Jeff
--
Jeff Garzik | Dinner is ready when
Building 1024 | the smoke alarm goes off.
MandrakeSoft | -/usr/games/fortune