>I've now added a few debugging points to jackd's alsa_driver.c: > - five checks for xruns in various parts > of alsa_driver_wait() (prints an error if xrun > is detected; check with snd_pcm_state()) > - prints an error if playback_avail or capture_avail > is not 1024 (period size in use) > - prints a warning everytime alsa_driver_wait() > takes more than 25msecs (23.2msec == period time) > >In the below test run, audio got garbled when the ecasound >subgraph timed out. To create the timeout I generated lot of cpu and disk >i/o stress. Few points to note: > >- no xruns are detected even though after the timeout > alsa_driver_wait() took 56.4msec which is more than > period_size * number_of_periods (1024*2/44100*1000=46msec); > in other words there should have been an xrun
i recall abramo saying that if the xrun happens within an mmap_begin/commit pair, the driver can't detect it, or something like that. i added kernel debugging to the hammerfall driver to check on aspects of this problem. it demonstrated that everything at the driver level was as expected. because this problem occurs on several different cards, i am starting to suspect part of jack's design rather than ALSA, but i have not yet managed to figure out what it could be. when i check the channel_area_t addresses used by jack, they also appear to be just as one would expect. btw, ctrl-c'ing jack_simple_client will cause a timeout 80% of the time on my machine, which is a simple, load-free way to create the problem. --p _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
