From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: HDSP 9652 MIDI - A timing disaster? Date: Mon, 13 Jan 2003 16:28:53 +0100 Sender: alsa-devel-admin@lists.sourceforge.net Message-ID: References: <200301131315.h0DDFrAk023523@spider.tela.com> Mime-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Return-path: In-Reply-To: Errors-To: alsa-devel-admin@lists.sourceforge.net List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: To: Clemens Ladisch Cc: Paul Davis , Mark Knecht , Alsa-Devel List-Id: alsa-devel@alsa-project.org At Mon, 13 Jan 2003 15:28:58 +0100 (MET), Clemens Ladisch wrote: > > Paul Davis wrote: > > >The hdsp driver doesn't send more than one MIDI byte per timer tick. > > >IMHO it should be modified to send in a loop until the FIFO is full > > > > that's what this tried to do: > > (...) > > how does this end up writing only a single byte? unless n_pending is > > always either 0 or 1, which on closer inspection, i see that it is > > ... yikes. > > > > >sending in output_trigger() instead of delaying it to the next timer tick. > > > > hmm. i modelled this code on another PCI driver that had MIDI > > support. is there an example you can point me to that starts from > > within the equivalent output_trigger? > > e.g. isa/sb/sb8_midi.c or drivers/mpu401/mpu401_uart.c > > And both output one byte at a time in a loop until the output fails. > (However, snd_sb8dsp_midi_output_write() doesn't check for a full FIFO.) well, generally it's not a good style to process in such a loop in the primary interrupt handler. we should rewrite them using tasklet... Takashi ------------------------------------------------------- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en