[linux-audio-dev] Re: image problem [was Re: [Alsa-devel] hel p for a levelmeter]

[STEFFL, ERIK (SBCSI)]

> -----Original Message-----
> From: Paul Davis [mailto:paul at linuxaudiosystems.com]
> 
>    [ 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.

  IMO it does not matter how well justified it is by POSIX or whatever else
if the end result is unusable system. In case of 'file' files it makes
(some) sense to block, however in case of sound I can't really think of
realistic situation where I would want to block. It's either busy (and let
program handle that) or realtime mixing should be offered. If they are
concerned about POSIX that blocking could be defualt, user would be able to
change it to either non-blocking returning EBUSY or non-blocking real time
mixing (sw, if card does not support it in hw)

  anyway, thanks for background info.

> >  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 ..."

  well:

  - let's kill the messenger,

  - that's what open source promises.

	erik