At Fri, 13 Sep 2002 11:41:17 +0200 (CEST), Jaroslav wrote: > > On Thu, 12 Sep 2002, Takashi Iwai wrote: > > > > The problem I have is that I do not see the use of generating a broken > > > pipe in this situation, the only scenario I can come up with is "oh, I > > > got a broken pipe, I must have forgotten to start the pcm, so I do it > > > and try writing again". But that scenario is highly unlikely to occur > > > in a program, and if it does, I would call it bad programming. > > > > > > For the blocking case, however, there is a use, that of having multiple > > > threads (or forked processes). In my case I have a input thread and and > > > output thread, and the sound-card is started from the input thread, > > > after the output buffer has been readily filled with data. Not that it > > > is hard to change my program to do like ALSA wants it, but I think the > > > behaviour is wrong, it is not what one would expect. > > > > we can see this problem from a different angle: on the current > > scheme, you cannot block writing if the stream is not running. > > writing more in the prepare state will always return an error > > immediately. > > > > btw, the attached patch is a quick and untested hack to change the > > behavior as you wish :) > > please give a try. > > I think that the current behaviour of write() is ok, the behaviour of > poll() might be "fixed". I see advantages for both. I would prefer to have > this configurable to satisfy multi-threaded applications. We can put a new > variable to sw_params.
a new sw_params was what i thought of firstly, too. but afterwars, i came to realize that changing this behavior according to the blocking flag is more logical. if it's on the blocking mode, the driver should block if it's possible to do write in future _by any chance_. if it's not on the blocking mode, the driver should return -EAGAIN. and, the behavior of poll() depends on the behavior of write(). if it blocks, then poll blocks, too. for me this sounds very simple and easy... Takashi ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
