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