Nils Goroll wrote:
> Garrett,
>
>> No, the problem is that the kernel/drivers keep running while
>> userland threads are suspended, and before they get fully resumed.
>
> Ah, I should have read more carefully. I thought you were talking
> about the common issue of non-RT processes not getting enough cycles
> to send audio data in time.
>
> What about this: Would it help to move the code starting audio replay
> outside the actual resume entry point and use timeout(9f) to call it
> with a little delay?
>
> Sorry if this is obvious and does not help - I guess I know far less
> then you about driver development and I have never done this, but as I
> replied once, I thought I should mention this simple idea.
timeout() might work, though I have to say, I'm not too thrilled with
it. It would still be a heuristic -- I don't know how long it will take
until userland is resumed and ready to go, so I'd be picking a number
out of a best guess effort. For some hardware, it may be too long, and
for others too short.
I'd really prefer to use a callback that is executed *after* user
threads are resumed.
-- Garrett
>
> Nils
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
