At Thu, 12 Sep 2002 13:48:56 +0200, Anders Torger wrote: > (...snipped the analogy of pipes...) > > Well, I have the same opinion, I'd just like to give another example > (actually the same all over again, but I want to make it obvious). For > a socket or a pipe, if noone reads from the other end, it will block > forever. Thus, a buggy program will dead-lock. I think this example > fits logically the case of writing to the sound-card but no-one starts > it. It should then block forever. agreed, although the alsa is already apart from the standard device operations (unlike normal devices, alsa needs an explicit set-up before read/write).
> 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. ciao, Takashi
pcm-poll-fix.dif
Description: Binary data
