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. > Now the next problem are delays. amidi through ice1724 prints the > rawmidi data a fraction of a second later compared to USB midi input. I > guess there is not much we could do about it. The format is a bit > different which probably does not matter: > > pavel@nahore:~$ amidi -l > Dir Device Name > IO hw:0,0 Audiotrak Prodigy 192 MIDI > IO hw:1,0,0 Keystation Pro 88 MIDI 1 > I hw:1,0,1 Keystation Pro 88 MIDI 2 > > ice1724 midi: > pavel@nahore:~$ amidi -p hw:0 -d > > 90 2D 5E > 2D 00 > 90 30 79 > 30 00 > > USB midi: > pavel@nahore:~$ amidi -p hw:1 -d > > 90 2D 4C > 90 2D 00 > 90 30 5E > 90 30 00 > > However, what makes a huge delay difference is the next step - aseqdump. > Here USB still outputs data immediately: > > pavel@nahore:~$ aseqdump -p 20:0 > Waiting for data. Press Ctrl+C to end. > Source_ Event_________________ Ch _Data__ > 20:0 Note on 0 41 94 > 20:0 Note on 0 41 0 > 20:0 Note on 0 45 80 > 20:0 Note on 0 45 0 > > > > Whereas through ice1724 midi it takes several seconds for the same notes > to appear in aseqdump: > > pavel@nahore:~$ aseqdump -p 16:0 > Waiting for data. Press Ctrl+C to end. > Source_ Event_________________ Ch _Data__ > 16:0 Active Sensing > 16:0 Active Sensing > 16:0 Active Sensing > 16:0 Active Sensing > 16:0 Active Sensing > 16:0 Active Sensing > 16:0 Active Sensing > 16:0 Active Sensing > 16:0 Active Sensing > 16:0 Active Sensing > 16:0 Active Sensing > 16:0 Active Sensing > 16:0 Note on 0 43 86 > 16:0 Note on 0 43 0 > 16:0 Active Sensing > 16:0 Active Sensing > 16:0 Active Sensing > 16:0 Note on 0 47 100 > 16:0 Note on 0 47 0 > 16:0 Active Sensing > 16:0 Active Sensing > 16:0 Active Sensing > 16:0 Active Sensing > 16:0 Active Sensing > 16:0 Active Sensing > 16:0 Active Sensing > > Google told me the "Active Sensing" messages are OK. Still, the whole > pack of lines appears at once, but with a huge delay. > > When hooking Qsynth to the inputs, notes through USB sound immediately, > Notes through ice1724 get delayed by several seconds, but mostly they > produce no sound at all. Surprisingly, the few notes which actually make > it through sound long (just like the piano sustain pedal). USB notes do > not have this effect. 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. Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
