At Mon, 03 Nov 2003 17:44:21 -0800, Steve deRosier wrote: > > It really doesn't matter to our app if it gets blocked or is not blocked > or if bytes get discarded during a physical cable disconnection, the way > it is designed it continues to grind on anyway and as such, when > reconnected and the buffer drains eventually all would be right with the > world again. BUT, something in Alsa breaks down in this instance and > doesn't just clear up. It drains the buffers, but after that no more > data that gets routed through the buffers ever ends up in the driver.
that's true. the drop call doesn't reset the local buffer at all. we should add a callback to reset the local device at the drop, if any. (snip) > > maybe it'd be better to add a timeout for the sanity check. firstly > > after the time out is detected, we can do some reset work on the > > device, e.g. flush the buffer, etc. > > (the communication over the ALSA sequencer is a different story, > > though...) > > > > eep! I'm not sure I want to get into figuring out a timeout thingy... well, it's not so terrifying stuff :) > Maybe better left to the application level, where the app can decide > that after getting some count of -EAGAIN responses in non-blocking mode > it can give up or send some sort of flush/reset command to the alsa system. that's also an alternative solution. still the proper method to reset fails currently. as you wrote, only reopening the device is the proper way. that should be fixed, too (as written above). > > well, until this is implemented, we can add the switch (e.g. a module > > parameter) for your behavior (ignore-buffer-overflow), so that the > > driver works at least for your purpose... > > > > Ok, but I'd rather find the root of the problem and come up with a clean > solution than depend on a special switch. I'll work on it a little and > propose a slightly different patch. Maybe I'll rework > snd_uart16550_output_write() a bit more drastically so that it works > better. Though I'm not sure what I can do to it that doesn't drop bytes > yet doesn't seem to lockup the rawmidi stuff by not removing data from > rawmidi buffers. If I can't find another way, I'll put in the parameter > as a work around until we can find a better fix. > > I'll work on this for a bit this week and propose a second patch. If > you can come up with any ideas of things to look at or other issues, let > me know. thanks. please note that we're reaching to the feature/code freeze for 1.0 right now (it's planned in this month). but, of course, the patch can be put soon after 1.0 is released. ciao, Takashi ------------------------------------------------------- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
