>It's true that the Trident IRQ acknowledge is probably broken at some
>level. I found, with small periods, that Trident chip acknowledges
>the IRQ more times, so it could be possible, that some interrupts are
>lost, too. You can look for the spurious word in the Trident interrupt
>handling routine for my hack against the multiple IRQ acknowledge.
those messages don't show up in these cases. i have seen 1 or examples
of them in /var/log/messages, but none during the tests i have been
running. all day yesterday, i got just one.
what's the story with this:
// outl((ST_TARGET_REACHED | MIXER_OVERFLOW | MIXER_UNDERFLOW),
TRID_REG(trident, T4D_MISCINT));
the OSS driver says:
/* manually clear interrupt status, bad hardware design, blame T^2 */
outl((ST_TARGET_REACHED | MIXER_OVERFLOW | MIXER_UNDERFLOW),
TRID_REG(card, T4D_MISCINT));
have you determined that this is not necessary?
i see 2 possible explanations here:
1) broken on this h/w (trident)
2) a real data race exists
which do you think it is?
looking more broadly, doesn't it seem that the alsa-lib sync call
should cause poll(2) to be usable for both read&write in a single
call? that is, we wouldn't wake up the sleeper if its in a poll table
corresponding to the other stream, just remove it from the poll table
we're handling right now? this doesn't need low level driver support
as abramo suggested - it can all be done in the midlevel code. i'm
not totally sure how easy this is - its not clear what happens if the
wait times out - i don't think that ALSA would get any notification of
that. still, it seems likely that this type of functionality can be
implemented (there are hints of it in the old kernel select
implementation in 2.0).
--p
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
