> > >>Where is BUG ?, or in cs46xx driver or in the ALSA PCM core somewhere ?, >>well, it's easy fixed in snd_cs46xx_playback_copy(...) doing a check. >>Then why it only happen with the alsaplayer, just no idea .... >> >>suggestions ... ?? comments .... ?? >> > >playback_copy shouldn't be called after hw_free. I don't see any error in >PCM core. The additional check would be dead code. It would be better to >determine the real problem. Do you know the order of syscalls? > That's exactly my thought. Adding a check in snd_cs46xx_playback_copy(...) works fine however it may not be the right solution to the problem.
It only happens to me with the "alsaplayer", so probably the alsaplayer is doing something special. The alsaplayer seems to have various threads: 10826 pts/1 S 0:00 alsaplayer -f 2048 10827 pts/1 S 0:00 alsaplayer -f 2048 10828 pts/1 S 0:00 alsaplayer -f 2048 10830 pts/1 S 0:00 alsaplayer -f 2048 10831 pts/1 S 0:02 alsaplayer -f 2048 10832 pts/1 S 0:00 alsaplayer -f 2048 10834 pts/1 RN 0:00 alsaplayer -f 2048 10835 pts/1 RN 0:00 alsaplayer -f 2048 Maybe the problem is some race condition, just a theory .... Is there way to debug the PCM core finding out what happens ?? /Benny ------------------------------------------------------- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
