On Thursday 09 October 2008 14:49:24 Stéphane Letz wrote:
> The code is the OSS backend for jackdmp:
>
> http://trac.jackaudio.org/browser/jack2/branches/solaris/solaris/oss/JackOSSDriver.h
> http://trac.jackaudio.org/browser/jack2/branches/solaris/solaris/oss/JackOSSDriver.cpp
Well, this is perhaps unrelated, but some parts are pretty dubious:
A. Why are the sample formats set by direct hex number, and not AFMT_S16_LE
etc.? That would make sense if you wanted to make this compilable under OSSv3
soundcard.h, but by using SNDCTL_DSP_COOKEDMODE, SNDCTL_DSP_GETERROR and
SNDCTL_AUDIOINFO, you've already assumed OSSv4 soundcard.h... I think the best
solution if you're worried about that case is to include a soundcard.h from the
OSSv4 distribution.
B. ioctls may succeed, but return a different result than desired. This is very
rarely the case on vmix devices, since they convert internally, but non-vmix
device may act like this. The code doesn't seem to ever check for that - I'd
have expected at least a warning..
e.g.
rate = 44100;
ioctl (fd, SNDCTL_DSP_SPEED, &rate);
// rate may well be returned as 48000.
C. The call for SNDCTL_DSP_SETFRAGMENT is clearly incorrect.
First, it should be made before setting format, channels, and speed, but
(AFAICT) after setting SNDCTL_DSP_COOKEDMODE:
http://manuals.opensound.com/developer/callorder.html
Second, The high part is set to 1, but the manual says that permitted
values are only from 2 to 0x7fff:
http://manuals.opensound.com/developer/SNDCTL_DSP_SETFRAGMENT.html
I'm not sure how OSS reacts to that argument. (I know that when using 0,
OSSv4 typically set the device to max. fragments, but other implementation
don't neccesarily act this way - e.g. ALSA's OSS emulation sets it to
lowest number 2 instead.).
Yours,
Yair K.
_______________________________________________
oss-devel mailing list
oss-devel@mailman.opensound.com
http://mailman.opensound.com/mailman/listinfo/oss-devel
