Abramo Bagnara wrote: >> let's imagine: >> >> * a single-threaded app. if the coder omits starting the stream before >> poll, he'll quickly find out that nothing is played/recorded, and that >> poll will hit the timeout, and consequently revise his code logic. > >It would be definitely not easy for the app. to detect *why* poll is >blocking and it'd needs time. I think it would be a bad solution.
snd_pcm_state_t s = snd_pcm_state (pcm); // or $ cat /proc/asound/card0/pcm0c/sub0/status # if all else fails. are enough to enlighten the coder in this case. besides, if this happens in a single-threaded program, the code is broken and should be fixed at coding, not execution time. >> * a multi-threaded app. it is *very* convenient not to do the 'easy' >> message passing for starting/stopping streams in many, many >> applications. all you have to do in the 'engine' thread is poll and >> process. i wonder if you can imagine how much easier things get when >> things work this way. > >This argument might be applied to every message passing need between >threads. Do we want to change an useful semantic to have just another >way to do an already easy task? I don't believe so. then take a look at how /dev/rtc does it. it does periodic irqs, much like a pcm. it is perfectly legal to poll /dev/rtc without setting it to trigger, in which case it will block until timeout. i don't see why alsa has to do things differently, it is supposed to be advanced *linux* sound arch after all, so make it act like other linux devices do, please. >> i mean, alsa is great, but why do you have to make it a pita to code >> for? > >I suppose you're exaggerating the thing to support your arguments, don't >you ;-) nope. coding the workaround around the broken poll behaviour definitely was a pita. besides, i don't get what you aim for. you're doing things in a non-standard way, and coders don't understand it. don't you care about your users? and if you do, don't you care about complying with linux standards? tim ------------------------------------------------------- Sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
