At Thu, 24 Apr 2008 22:47:54 +0200, Pavel Hofman wrote: > > Takashi Iwai wrote: > > At Wed, 23 Apr 2008 22:19:04 +0200, Pavel Hofman wrote: > >> Pavel Hofman wrote: > >>> Takashi Iwai wrote: > >>>> At Tue, 22 Apr 2008 22:23:55 +0200, Pavel Hofman wrote: > >>>>> Hi, > >>>>> > >>> ........... > >>>>> After the playback stops, the interrupts are gone too. It > >>>>> seems as if the playback interrupt initiates the MPU TX > >>>>> interrupt. > >>>>> > >>>>> If we could avoid generating the MPU TX interrupt during > >>>>> regular playback, I believe the major problem would be > >>>>> resolved. > >>>>> > >>>>> Even if I mask the interrupts (CCS01) and do not explicitly > >>>>> unmask them (according to proc ice1724 the CCS01 register > >>>>> stays at 0xa0), the interrupt gets generated. > >>>> OK, then the simplest way would be to just ignore the TX bit at > >>>> the second or later check. > >>>> > >>>> How about the patch below? > >>> Takashi, thanks for the hack idea. The overhead is just one more > >>> loop which is nothing. I will test it and post details of further > >>> problems (there is a bunch of them :) ) > >>> > >> Hi, > >> > >> The hack works fine, I am finally getting no CPU burning during > >> playback and MIDI input/output. > > > > Thanks for checking. The fixed patches are on HG tree now. Please > > sync your tree. > > Takashi, the patch you put into HG was not the one I sent you, but sort > of the original one that I said did not work. > > pavel@nahore:~$ amidi -p hw:0 -d > ALSA lib rawmidi_hw.c:233:(snd_rawmidi_hw_open) open /dev/snd/midiC0D0 > failed: Input/output error > cannot open port "hw:0": Input/output error > > amidi -p hw:0 -S > F0411042110C000000000074FF0411042110C000000000074F7F0411042110C000000000\ > 074F7F0411042110C0F0411042110C000000000074FF0411042110C000000000074F7F041\ > 1042110C000000000074F7F0411042110C0 > ALSA lib rawmidi_hw.c:233:(snd_rawmidi_hw_open) open /dev/snd/midiC0D0 > failed: Input/output error > cannot open port "hw:0": Input/output error > > I do not know the reason for MPU401_INFO_NO_ACK. You removed it from the > original patch, but without it I always get the input/output error. Ah, thanks, I overlooked it. Fixed now. > >> ................ > > > So, now it's a problem of MIDI "input", if I understand correctly? > > What we need to check at first is whether the MPU_RX irq is issued at > > the correct timing. If not, check whether MPU watermarks > > (MPU_FIFO_WM, CCS0E). According to the datasheet, the values are 0 > > for both RX and TX. > > MPU_RX irq did not get fired at all, even though the IRQ mask register > CCS01 was 0x00, i.e. all interrupts enabled. I enabled the watermarks > and that did the trick :) MPU_RX gets fired now, the delays are gone and > Qsynth plays find with MIDI from USB or ice1724 input. Great, fixed on HG as well. > It still feels as > if midi from ice1724 has a little bit higher latency but I do not think > we can do anything about it (plus it may just be my subjective feeling). This might be the difference between the transport ways. USB can be faster. > I am enclosing a patch to current HG which does not produce errors and > puts HG to the functionality I have now. MIDI input works correctly. > MIDI output is not physically tested, I only checked that > snd_vt1724_mpu401_write gets called with reasonable data. That should be enough. Thanks for your testing! Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
