Re: i810 audio patch

Doug Ledford
2001-12-04T23:05:26Z

> Doug Ledford wrote:
>
>> Probably not. Although I did change it back but then change it in
>> another way. Use the attached patch to back out those changes and let
>> me know if it works (for some reason, I doubt it).
>
>
> Fascinating...
>
> Your patch to i810_poll fixes the sleep of death. and with the rest of
> the patches in 0.07, select() works a lot better but still not perfectly.

That's because my previous patch would set the poll mask and return on
the first call in because there was space already available. However,
the initial call into poll() at the vfs layer evidently sets the state
of the process to interruptible sleep, and then poll_wait() sets it back
to running. So, when I skipped the call to poll_wait(), I wasn't
manually setting the task state back to running, and as a result the
code would return, but the calling program (artsd) would be set to a
sleeping state in the scheduler and would never get woken back up. An
alternative fix would have been to set the task state to running before
leaving the poll function manually instead of relying upon poll_wait()
to do it for us.

> xmms+artsd is likely to play sound for quite a while, *until* I do
> something that causes another process to be scheduled, like click on the
> Mozilla window that's sitting in the background. At that point, it
> reverts to the behavior where select() doesn't return properly. And
> stays that way.

>

> this may be due to an output underrun... or i suppose lost interrupt is
> also possible.
>
> i think it might be wise to use
> get_available_read_data/get_free_write_space from i810_poll instead of
> dmabuf->count directly. i'll try this and see if it works...
>

--

Doug Ledford <dledford@redhat.com> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems