[ re: OSS ] >> code. It will >> soon be available only through emulation. It forces use of >> the blocking >> model.
actually, it doesn't. nothing would stop the implementation of an OSS driver/client for JACK. >> ALSA is very powerful and complete, but very complex. This will make > > <rant> > > it is also pretty much useless for general users. I mean if I can't listen >to mp3 and browse the web at the same time ... (without sound servers which >were discussed recently and as far as I can tell the general consensus is >that they are bad and not to be used). Is there any rationale for the >blocking behaviour? I mean I can't imagine situation where I would want to clarify: the "blocking model" that joshua was describing has nothing to do with the "blocking behaviour" that you are describing. jaroslav (aka "mr. alsa") has justified the block-on-open model by reference to POSIX standards for the open system call. its a bit debatable, but his point of view on it is at least as close to standard POSIX behaviour as yours. applications can avoid this quite easily using O_NONBLOCK in the OSS open call (or its equivalent for ALSA), later followed by fcntl(2) if necessary. i personally it would have been better to make open return EBUSY, but the problem is that there is no flag for open(2) that says "block even if busy", so with that design there is no way to get "block-on-open" if desired. > except of the blocking of sounds (the problem mentioned above) I am quite >dissapointed by functionality of linux drivers I have tried, I have sb live >platinum and (last time I checked): "i am quite disappointed that a group of volunteers who work for no monetary compensation have failed to implement all the features i want. i haven't offered to pay them, but i really hope they get all these features working really soon because its really irritating not being able to ..." --p
